ftp.whtech.com

home *** CD-ROM | disk | FTP | other *** search

/ ftp.whtech.com / ftp.whtech.com.tar / ftp.whtech.com / datasheets and manuals / Hardware / ti hardware compendium.txt < prev next >

Wrap

Text File | 2006-10-19 | 293KB | 6,481 lines

============================================================================ TI Hardware Manual. This document started life as a compendium of information on different memory acess methods for memory cards on the TI-99/4a home computer. Different pieces of good technical messages and articles have been sewn together that were sitting around on my hard drive. My hope is that this information will be of use to other remaining TI Hobbyist. This compendium of information is copyrighted material of Dan Eicher, and my not be edited, changed or redistributed. All articles and message, individually remain the exclusive property of their authors. As time permits I will add more information to this document. If you have anything you wouldn't mind contributing, I will be pleased to add it. If you find information that is in error, please send me an update and that will also be added. If you have comments like, gee... can you add this that or the other, or I would have done it this way ect... Please send all of these comments to NoOneCares@Null.Com. Thanks to the following TI Enthusist for their contributions: Paolo Bagnaresi Jerry Coffey Bruce Harrison Beery Miller Jim Ness David Nieters Thierry Nouspikel Don O'Neil David Ormand Jeff H. White Dan H. Eicher Eicher@Delphi.Com www.delphi.com/people/eicher L.D.O.M. 12.29.96 ========================================================================== INDEX Myarc 512K Memory Card. From Myarc Documentation....................................DTIHM001 Foundation 128K Memory Card. From Foundation Documentation...............................DTIHM002 Rambo. Excerpt from the Horizon Manual.............................DTIHM003 AMS Memory Expansion Card. by Bruce Harrison...........................................DTIHM004 Corcomp Memory Expansion Card. by Jeff White...............................................DTIHM005 Western Horizon Technology AT Keyboard Interface. by Don O'Neil...............................................DTIHM006 by David Nieters............................................DTIHM007 MBP - Clock A/D&D/A. by Dan H. Eicher............................................DTIHM008 Super Space. from Information found in Micropendium......................DTIHM009 Super Space II Cartridge. from Original Documentation - Thanks to David Ormand........DTIHM010 Internals of the DEC command. by Jeff White...............................................DTIHM011 99/4a clock speeds and assembly timing. by Jeff White...............................................DTIHM012 The TMS9985. by Dan Eicher...............................................DTIHM013 The TMS99105A. by Dan Eicher...............................................DTIHM014 Bugs in the console interupt routine. by Jeff White...............................................DTIHM015 Setting up user interupt routines. by Jeff White...............................................DTIHM016 Interupts by Jim Ness.................................................DTIHM017 RS232 Circular Interupt Buffer. by Texas Instruments........................................DTIHM018 Corcomp RS232 & PIO internals. by Jeff White...............................................DTIHM019 Bringing your Myarc RS232 into the 90's by Jeff White and Dan Eicher................................DTIHM020 A definition of skew. by Jeff White...............................................DTIHM021 3.5" Drives and the Geneve. by Jeff White...............................................DTIHM022 Disk Controllers -- an Addendum March, 1987 by Jerry Coffey.............................................DTIHM023 A Hard Drive Odessey (Oddity) By Dan H. Eicher and Jeffrey H. White.......................DTIHM024 The 9224: A failed experiment or an educational experience? by Dan H. Eicher and Jeffrey H. White.......................DTIHM025 Fixing Blown Bit Maps on the HFDC by Edward Hallett...........................................DTIHM026 VDPID & CPUID by Jeff White...............................................DTIHM027 An Explination of Bit Map Mode by Jeff White...............................................DTIHM028 Graphics 4 Mode Tutorial by David Nieters............................................DTIHM029 In search of.... Leading Edge Connectors. by Dan H. Eicher............................................DTIHM030 Modify the Rave Speech Card and MBP Card for use with the Geneve. by Beery Miller.............................................DTIHM031 Pin definition for the new Rave expansion box. re-typed by Dan Eicher......................................DTIHM032 TI-99/4 - THE EARLY DAYS by Herbert H. Taylor.......................................DTIHM033 9900,9901,9902,9904 by Definitions by Dan Eicher...............................................DTIHM034 Console Connectors by Thierry Norspikel........................................DTIHM035 How to adapt Atari joystick to work on the TI. Author Unknown..............................................DTIHM036 Grand Ram Technical Manual by DataBioTics & SofMachine Inc.............................DTIHM037 Myarc FDC Technical Information/Manual by Paolo Bagnaresi..........................................DTIHM038 DX-10 OPCODES AND MNEMONICS by Texas Instruments Inc....................................DTIHM039 ============================================================================= DTIHM001 Accessing Extra Memory on the Myarc Memory Expansion Card. From the Myarc Memory Expansion Manual.... To access the additional 96K or RAM (in addition to the standard 32K) with assembly language, the following is a useful discussion on its operation. The 128K RAM is divided into 4 banks of 32K each. When enabled, each bank occupies memory locations >2000->3FFF and >A000-FFFF. The mechanism to select a particular memory bank is determined by CRU bits >1002 and >1004. When these bits are zero, the normal 32K memory expansion is enabled. The other 3 banks are selected by setting the proper combination of bits. The following examples show how to select each of the four memory banks from assembly language excuting from "PAD" RAM: Select Bank 2 Select Bank 4 LI R12,>1000 LI R12,>1000 SBO 1 SBO 1 SBZ 2 SBO 2 Select Bank 3 Select "Standard 32K Ram" LI R12,>1000 LI R12,>1000 SBZ 1 SBZ 1 SBO 2 SBZ 2 Note: 512K card uses the additional CRU bits >1006 and >1008 to access the additional banks. LI R12,>1000 SBZ 1 \ SBZ 2 \ This would select the Standard 32K Ram Memory. SBZ 3 / SBZ 4 / Note: These cards respond at >1000 + >1900! A simpler way to page the Myarc memory cards is with LDCR instructions. Here are a few examples: BANK1 BYTE 0 BANK2 BYTE 1 BANK3 BYTE 2 BANK4 BYTE 3 BANK5 BYTE 4 ... (assign byte values 5 thru 12 to BANK6 thru BANK13) BANK14 BYTE 13 BANK15 BYTE 14 BANK16 BYTE 15 Select Bank 1 Select Bank 13 Page through banks LI R12,>1000 LI R12,>1000 LI R12,>1000 LDCR @BANK1,4 MOVB @BANK13,R1 LI R1,BANK1 LDCR R1,4 LI R2,16 NB LDCR *R1+,4 Page backward all banks DEC R2 LI R12,>1000 JNE NB LI R1,BANK15 PB LDCR R1,4 JEQ FI DEC R1 JMP PB FI ... (next instruction) ============================================================================= DTIHM002 Foundation 128K Card The Myarc Memory Expansion card is almost identical to the Foundation card, the only real difference is the CRU address for banking. These two cards are so close that Travis Watford produced an article on how you could upgrade a Foundation 128K Card to 512K and make it so that it could accept a Myarc 512K DSR eprom. It should be noted, orginally the Foundation came with NO DSR eprom and was strictly usable as memory expansion. CRU ADDRESS Select Bank 2 Select Bank 4 LI R12,>1E00 LI R12,>1E00 SBO 1 SBO 1 SBZ 2 SBO 2 Select Bank 3 Select "Standard 32K Ram" LI R12,>1E00 LI R12,>1E00 SBZ 1 SBZ 1 SBO 2 SBZ 2 ============================================================================== DTIHM003 From the Rambo/Horizon User Operating Manual Rambo This section of the manual will try to explain the memory managment sub-program called >B0 and how to interface with it using assembly code. This low-level sub-program will only work on Horizon cards with the RAMBO hardware installed. If you need more help on using the sub-program see section 5.6 of this manual. The orginal Horizon hardware only allowed the Horizon memory to be accessed in 2K blocks at the DSR space from >5800 thru >5fff. The rest of the DSR space from >4000 thru >57ff was reserved for the Horizon ROS. This limited access to the memory on the Horizon card was fine for uses like a ramdisk, but to write a program which really executed from and used the Horizon memory was almost impossible. There needed to be a new way of accessing the Horizon memory, but without losing the wonderful and powerful ramdisk features and functions. With this in mine, we decided to design a simple upgrade kit for all Horizon cards which would allow the upgraded Horizon to work the same in the original Horizon mode; but when accessed thru a new mode it would switch to a whole new paging system which would be better designed for writing large programs, etc. The ROS would also have to be upgraded to support the new mode by adding a super memory management sub-program to ease in the writing of large programs as well as allowing both ramdisk files and program space to share the same memory. Finally, with the RAMBO hardware and the SERIES 8 software, it was now possible to write large programs or programs which used the RAMBO program space for DATA storage very easily. The SERIES 8 software added a sub-program called >B0 to handle the complex memory management needed to make sure all programs run perfectly without destroying any files or other programs which may be sharing the memory on-board the Horizon card. All the values for the sub-program >B0 are transfered thru CPU PAD addresses, which will be explained later on. Access to the sub-program >B0 is similar to the normal DSRLNK type >8 which is for DSR devices like "DSK1.", and "RS232."; except the DSR only needs a 2 byte VDP PAB of >01B0, the first byte being the length, and the second byte being the sub-program name >B0. The following section is divided into five different parts, the first two explaining the CRU interface bits, and the last three explaining the three different ways to access the sub-program >B0. ORIGINAL HORIZON CRU INTERFACE ACCESS: The orginal Horizon interface has a CRU address range from >1000 thru >1700, and the 8 or 16 CRU bits are defined as follows: CRU BITS | Definition fo the CRU interface bits (15=MSBit / 0=LSBit) ----------------------------------------------------------------------- 0 = 6K >4000 OFF/ON (0=ROS OFF, 1=ROS ON) Ised by ROS and DSRLNK 1 thru 7 = 2K >5800 Page number 0 thru 127. (Max. of 256K for 8K*8 cards). 8 thru 9 = Select one of four banks of 256K of memory. (Max. of 1024 for 32K*8 cards). 10 thru 11 = Select one of four banks of 1024 of memory. (Max. of 4096K for 128K*8 cards). 12 thru 14 = Undefined, may be used on a future series of Horizon cards. 15 = Reset to 0: Used to change to RAMBO mode, on original Horizons it was undefined. RAMBO CRU INTERFACE ACCESS: A Horizon card with RAMBO installed can work the same as an original Horizon as detailed above or when bit 15 or the CRU interface is set to 1, it can be accessed as follows: CRU BITS | Definition fo the CRU interface bits (15=MSBit / 0=LSBit) ----------------------------------------------------------------------- 0 = 6K >4000 OFF/ON (0=ROS OFF, 1=ROS ON) Ised by ROS and DSRLNK 1 thru 2 = Not used when in RAMBO mode, recommended both be reset to 0. 3 thru 7 = 8K >6000 Page number 0 thru 31. (Max. of 256K for 8K*8 cards). 8 thru 9 = Select one of four banks of 256K of memory. (Max. of 1024K for 32K*8 cards). 10 thru 11 = Select one of four banks of 1024K of memory. (Max. of 4096K for 128K*8 cards). 12 thru 14 = Undefined, may be used on a future series of Horizon cards. 15 = Set to 1: Used to change to original Horizon mode. ACCESS MODE #1 FOR SUB-PROGRAMS >B0 (Gets Max. number of free 8K pages): >834A IN Must be cleared before access to get true number of free pages. OUT Max. number of free 8K pages for all RAMBO's in the TI system. >834C IN >0000 = Gets the Max. number of free 8K pages in the system. OUT Not changed, will be the same value as IN. >8350 IN Not used for input to the sub-program >B0. OUT >0000 if no errors, or >FFFF if errors where detected. Accessing >B0 with >834A and > 834C cleared will, upon exit, return to the program in >834A the max. number of free 8K pages for all RAMBO's in the system. This access causes all cards to be switched to orginal Horizon mode, and being so can't be accessed from within the >6000 thru >7FFF space. The following is an assembly example which is accessed like: BL @GETMAX REF VMBW,DSRLNK Normal VMBW and DSRLNK E/A BLWP's. GETMAX CLR @>834A Clear Max. number of pages. CLR @>834C Ask for max. number of free 8K pages. LI R0,VDPPAB Address of the PAB in VDP memory. LI R1,CALLBO Address of the PAB in CPU memory. LI R2,2 Length of the PAB to be written to VDP memory. BLWP @VMBW Write the PAB (>01B0) to VDP memory. MOV R0,@>8356 Make >8356 point to the length byte of the PAB in VDP ram. BLWP @DSRLNK Execute the sub-program >B0. DATA >A MOV @>8350,R0 Check for errors. EQUAL BIT IS SET IF NO ERR! RT Return to program. CALLBO DATA >01B0 PAB data for sub-program >B0. ACCESS MODE #2 FOR SUB-PROGRAM >B0 (Selects an 8K page and turns on RAMBO): >834A IN Not used for input to the sub-program >B0. OUT CRU address of the RAMBO/HORIZON card that is currently on. >834C IN A page number from 1 to max. number of free 8K pages. OUT The 16 bit CRU value used to select the page and turn RAMBO on. >8350 IN Not used for input to the sub-program >B0. OUT >0000 if no errors, or >FFFF if errors where detected. Accessing >B0 with >834C containing the number of the page you want will turn on the correct RAMBO/HORIZON card and then select the page you specified, and upon exit will return the CRU address and CRU value used to select the page in >834A and >834C. This command also overrides any cartridge which may be plugged into the module port, and will also turn off the P-Gram card if it was on. This function makes sure no other device is responding at the same >6000 space of memory. The following is an assembly example which is accessed like: BL @SETPAG with the next line containing a line of DATA with the number of the page you want. REF VMBW,DSKLNK Normal VMBW and DSRLNK E/A BLWP's SETPAG MOV *R11+,@>834C Get number of the page to select. LI R0,VDPPAB Address of the PAB in VDP memory. LI R1,CALLBO Address of the PAB in CPU memory. LI R2,2 Length of the PAB to be written to VDP memory. BLWP @VMBW Write the PAB (>01B0) to VDP memory. MOV R0,@>8356 Make >8356 point to the length byte of the PAB in VDP. BLWP @DSRLNK Execute the sub-program >B0. DATA >A MOV @>8350,R0 Check for errors. EQUAL BIT IS SET IF NO ERR! RT CALLBO DATA >01B0 PAB data for sub-program >B0. ACCESS MODE #3 FOR SUB-PROGRAM >B0 (Turns off all RAMBO/HORIZON cards): >834A IN Not used for input to the sub-program >B0. OUT Not changed will be the same value as IN. >834C IN >FFFF = Tell all cards to switch back to original Horizon mode. OUT Not changed, will be the same value as IN. >8350 IN Not used for input to the sub-program >B0. OUT >0000 if no errors, or >FFFF if errors where detected. Accessing >B0 with >834C containing >FFFF will tell all the Horizon cards in your computer system to switch back to original Horizon mode. This call, since it will remove any page at >6000, can't be accessed from the >6000 space. If for some reason a RAMBO program doesn't switch all the cards back to original Horizon mode, the ROS will do a complete reset any time the TI Title Screen appears. The previous assembly examples should be enough to firure out how to use this mode of sub-program >B0. ============================================================================== DTIHM004 The AMS Memory Expansion Card. AN ADVENTURE WITH AMS FROM TWO VIEWPOINTS By Bruce Harrison & Lew King People are buying the Advanced Memory System (AMS) now that it's being produced and sold by the SW99ers of Tucson, AZ. One of those customers is Lew King, from Industry PA, who's co-authoring this article. His perspective as an owner will follow, but for the moment it's the viewpoint of an experienced Assembly programmer. There are two potential kinds of applications for the AMS memory card. One is the creation of massive programs, in which the code to operate the program needs more than 32K of RAM. That's not the forte of this particular Assembly programmer. The second kind of application is one in which the program itself occupies only part of the 32K memory, but the program needs large blocks of memory to handle data. For example, you might have a word processor like Funnelweb where the text buffer could be expanded to perhaps 16 times what Funnelweb could normally handle. Now that's the kind of application that gets Bruce Harrison's attention. At the M.U.G. in Cleveland, Lew King bought his AMS card, with 256K capacity. When I asked what he'd do with all that memory, he quickly came up with an idea for me to pursue. Some time back, I produced my Video Titler program, which uses Bit Map images. Just one such image (for example a TI-Artist picture with color included) occupies 12K bytes of memory. Two such images completely fill the high portion of the 32K memory. Thus in the original Video Titler, the program code and internal data had to fit entirely in low memory, starting at >2678, so that all of high memory from >A000 thru >FFFF could be used to store two complete bit-map color pictures. That meant that after just one "wipe" transition, the user would have to pause the VCR, load the next frame from disk, then proceed to the next transition. That works, but it's labor intensive and slow work for the user. Lew immediately saw the possibility for pre-loading many frames into the AMS, so that pauses for re-load from disk would be minimized. Having this idea to work with was of course just the start. To make a working program, we had to have some definitive words on how to take advantage of the AMS in terms of Assembly Source. Nobody at the Cleveland gathering had that kind of information at his fingertips. There is no published source (until now) for that kind of information. After a couple of unsuccessful attempts to get the needed information, I asked Lew to print out and send me the "docs" that were delivered on disk with his AMS card. Lew complied, and within two days I had printed docs plus several disks. As it turned out, it was fortunate indeed that Lew included those disks, because one of them contained a source file called AMSINI. That sounded like it could be important, and it was. AMSINI contained the key source code segments to make use of the card. There was still a problem, however, in that some of the material in the printed docs contradicted parts of the AMSINI source file. After working through a chain of informants, I got in touch with Rich Gilbertson, who was making a version of his RXB product for the AMS card. Rich filled in the gaps, telling me that the printed docs were wrong and the AMSINI file correct. He pointed out all the non-obvious things, like the fact that in its power-up condition certain pages of the AMS are pre-assigned to the low and high portions of 32K memory. Pages 2 and 3 are the low memory, and pages 10 (>A) through 15 (>F) are assigned as the high memory. In other words, if your program loads in low memory, it will reside in pages 2 and 3 of the AMS, and if it writes to or reads from high memory, that will go into and come from pages >A through >F of the AMS. (One page is 4K of memory. Pages >A through >F will hold 24K bytes.) Among other things, this means that pages 0 and 1 and the group of pages from 4 through 9 are unused in the power-up configuration. Pages beyond 16 (>10) are also unfilled on power-up. Some programmers (including Rich Gilbertson) prefer to leave pages below 16 (>10) unused, reserving them for future use with an alternate operating system. Being an old curmudgeon who doesn't believe any such operating system will ever emerge, I decided that pages below 16 would not be left alone by my Video Titler program. But first, since AMS cards come in various configurations, with capacities of 128K, 256K, and even 512K, I had to have a way for my program to measure the amount of memory that was present, and adapt its operation accordingly. Fortunately, that AMSINI file on the disk contained just such a program segment. I adapted that slightly, so it would measure page by page starting at 16 and going to whatever was the highest page available. Since pictures occupy three pages each, I divide the number found by three to find the number of "frames" that can be stored in the memory above page 15. In the Video Titler case, we can use pages 10 thru 15 to store two more frames, since the entire program remains in low memory, pages 2 and 3. Now let's suppose we've got a card with only 128K memory. There will be only 16 pages above 15, and using them in groups of 3 will mean only 5 frames there. Adding the two frames in pages 10 thru 15 means seven frames can be stored. If we use that unused space from page 4 thru 9, two more frames can be stowed, for a total of nine. Thus in the program we take the number of pages beyond 15, divide that by three (ignoring any remainder) and add 4 to come up with the total number of frames we can keep in memory. For Lew King's card, with 256K capacity, there are 48 pages past 15, so a total of 20 frames can be stored. For 512K capacity, a whopping 41 frames could be put into memory. In the sidebar for this article are a couple of "snippets" of source code that may be helpful to anyone trying to make use of the AMS card for data-intensive applications. First in that is a "complete program" section called AMST. This was the first thing I sent to Lew King for testing. This little program, if run on my own machine, which has no AMS card, will simply report that fact. On Lew's machine, it reports 48 Pages and 20 Frames as the capacity of his AMS card. This source can be modified easily to report in different ways. For example, you could take the number of pages above 15, add 12 for the pages from 4 thru 15, then multiply by 4 to indicate available capacity in KiloBytes. ACCESS and MAPPING To use other than the default setup, you have to do two things. First, you have to "turn on" the card's memory in the >4000 block and write to the mapping registers there. Second, you have to "turn on" the mapper function to make what you've written into the >4000 block take effect. The first step in all this is to set Register 12 to the value >1E00, which is the CRU address of the AMS card. Now doing a SBO 0 instruction will enable the >4000 memory block for reading and writing. In that block, each word starting with >4000 and ending with >401E acts to control what page maps into what memory location. The subroutine AMSINI (see sidebar) initializes all the mapping registers to power-up condition. Thus, for example, >4004 is set for page 2, >4006 to page 3, etc. In our own program, we're mapping things into the >A000 through >F000 blocks. Thus the registers we write to in >4000 are at >4014 thru >401E. To make a mapping selection, we write the desired page number to the high order byte of the control register. Let's take a concrete example. Suppose we want pages 4, 5 and 6 of the AMS to behave as if they were at >A000, >B000, and >C000. It's this easy: LI R12,>1E00 CRU ADDRESS SBO 0 TURN ON CARD'S >4000 BLOCK LI R1,>0400 PAGE NUMBER IN LEFT BYTE LI R3,>4014 MAPPING REGISTER FOR >A000 BLOCK MOV R1,*R3+ WRITE TO >4014 AND ADD 2 TO R3 AI R1,>100 LEFT BYTE OF R1=5 MOV R1,*R3+ WRITE 5 TO >4016 AND ADD 2 TO R3 AI R1,>100 LEFT BYTE OF R1=6 MOV R1,*R3 WRITE 6 TO LEFT BYTE AT >4018 This sets the registers, but does not actually start the mapper working. To put the mapping in effect, we have to perform one more operation: SBO 1 TURN ON THE MAPPER Now that the mapper is turned on, anything written to >A000 thru >CFFF will actually be written into pages 4 thru 6 of the AMS memory instead of into pages >A thru >C. Similarly, any memory reading from >A000 thru >CFFF will actually read the contents of pages 4 thru 6 of the AMS memory. Thus your program can write and read as if to >A000 thru >CFFF, but the mapper will make things actually access the pages 4 thru 6 in the AMS card. You can turn off access to the card's >4000 block and still leave the mapper in effect by the instruction SBZ 0. (Provided R12 still contains >1E00.) You can turn off the mapper by SBZ 1, and then the areas >A000 thru >CFFF will revert to "normal", reading and writing to pages >A thru >C of the AMS card. In the finished AMS version of Video Titler, the program works by frames, where each frame accounts for three pages of the AMS memory. We use an odd-even scheme, so that odd numbered frames (1,3,5,...19) go into pages mapped to >A000 thru >CFFF, and even numbered ones go into pages mapped to >D000 thru >FFFF. This way the program always has immediate access to two frames at any given time. Let's say for example that the user asks to load a TI-Artist picture (with color) into Frame 1. We take the desired frame number, multiply that by three, add one, then put that in the left byte of a workspace register. Since this is an odd frame, we use the mapping registers at >4014 thru >4018, and put 4, 5, and 6 into the left bytes of those mapping registers, respectively. (For an even page, we'd use >401A thru >401E.) Now when the program reads the file, it dumps the contents of the pattern and color parts into >A000 thru >CFFF, which really goes into pages 4 thru 6 of the AMS memory. In similar fashion, frame 2 goes into pages 7 thru 9, frame 3 into pages 10 thru 12, frame 4 goes to pages 13 thru 15, and so on until frame 20, which goes into pages 61 thru 63. Clear as mud? Look at Part Two of the Sidebar, which may help. Meanwhile, how about a little different perspective? The AMS Owner's Viewpoint The Super AMS card is a most welcome and needed addition to the TI 99/4A. The physical aspects are a well-made, high-quality card which inserts in place of the 32K card. In normal use, it duplicates the 32K card exactly, except for the absence of an indicator light. In expanded mode, the card provides from 128K to 1 meg of paged memory, depending on the chips installed. There are three disks of software provided with the card, of which two are archived. Included is an excellent memory tester that writes and reads to every bit. This assures the user that everything is functioning properly. Also included is an excellent disk copy program, AMS Copy. The program reads an entire 720 sector disk into memory, then writes to the copy disk in one pass. Contents of the master disk remain in memory, allowing as many copies to be made as needed without re-reading. Also there were two games, which I could not get to run. The remainder of the software is mainly for programmers and of little consequence for the end user. So, aside from testing the memory and copying disks, what can be done with the Super AMS card? Well, prior to the middle of July, the answer was "not too much." Enter Bruce Harrison. When I first purchased the Super AMS card back in May at Cleveland, Bruce rather poo-pooed it, saying that he could write any program for the TI and keep it well within the 32K space. No argument here. Then I posed the hypothetical question....how many titles could the Video Titler program hold in 256K of memory? To which Bruce answered, "I'll think about it." Well, Bruce did a lot of thinking and a lot of programming. The result.... the Video Titler can now hold up to twenty color graphic files in memory on a 256K card. Super. They are instantly available using any of the many different wipes in the program. If you make a mistake, or change your mind, any frame can be reloaded without changing the others. The sequence can also be started at any frame. Anyone who has previously used the Video Titler will most certainly appreciate the new features, added versatility, speed, and power of the new AMS Video Titler. The entire operation of paging twenty titles into memory, then using them is totally seamless and transparent to the user. It is as though the TMS9900 had twenty address lines. Substantial documentation is included with the program, but I dare say that most folks won't read them. Aside from possibly looking up which keys to use for what wipes, the Titler is that easy to use. When you are ready to quit, the Titler returns nicely to the E/A menu screen. It's rather ironic.... To the best of my knowledge, Bruce Harrison is the first programmer outside of the SAMS development team to make any real productive software for the Super AMS card. Yet, he is the one programmer that never received a card to use. The AMS Video Titler beta copy worked flawlessly the very first time. This is a real tribute to outstanding programming ability. Programmer's Update Since the above was written, I have received a set of the AMS documentation and an offer of a card from David Ormand of the SW99ers. David has been sent a copy of the AMS Video Titler and a letter accepting the offer of a card to use for programming and testing my new products designed for use with AMS. * SIDEBAR PART ONE - A TEST PROGRAM * COMPLETE AS SHOWN * * TEST PROGRAM FOR AMS CARD * SPECIAL BY B. HARRISON * FOR TITLER AMS VERSION * AMST/S REF KSCAN,VMBW DEF START KEYADR EQU >8374 Key-unit address KEYVAL EQU >8375 Reported keystroke STATUS EQU >837C GPL STATUS BYTE GPLWS EQU >83E0 GPL workspace GR4 EQU GPLWS+8 GPL Reg 4 GR6 EQU GPLWS+12 GPL Reg 6 STKPNT EQU >8373 stack pointer LDGADD EQU >60 load grom address address XTAB27 EQU >200E a storage location GETSTK EQU >166C get stack START LWPI WS LOAD OUR WORKSPACE BL @AMSINI USE AMS INITIALIZE SUBROUTINE (BELOW) C R1,@>401E AMS CARD PRESENT? 0=NO 401E=0F0F=YES JNE NOAMS IF NO AMS CARD, JUMP AHEAD SBO 1 TURN ON MAPPER CLR R1 R1=0 CLR R4 R4=0 MOV R1,@>401E SET >F000 TO PAGE >00 MOV R1,@>F000 SET FIRST WORD PAGE 0 TO 0 LI R3,>8000 R3 TO PAGE >80 MOV R3,@>401A SET >D000 TO PAGE >80 LI R1,>0F00 START AT PAGE 15 AMSLP1 AI R1,>100 ADD ONE PAGE INC R4 INC NUMBER FOUND MOV R1,@>401C SET >E000 TO PAGE 16, 17, 18, ETC. MOV R1,@>E000 LOAD >E000 WITH PAGE # C R1,@>E000 DID IT LOAD? JNE AMSDO IF NOT, WE'RE BEYOND LAST PAGE C @>F000,@>E000 CHECK PAGE 0 FOR CHANGE JEQ AMSDO IF EQUAL, JUMP CI R1,>9000 LIMIT NUMBER? JL AMSLP1 IF LESS, REPEAT C @>D000,@>E000 CHECK PAGE 80 FOR CHANGE JNE AMSLP1 IF NOT EQUAL, REPEAT AMSDO DEC R4 ONE LESS (R4 EQUALLED PAGE NOT FOUND) MOV R4,@AMS SAVE NUMBER OF PAGES ABOVE 15 BL @AMSINI AMS INITIALIZE (BACK TO "NORMAL") SBZ 0 TURN OFF CARD - MAPPER STILL ON SBZ 1 TURN OFF MAPPER JMP REPORT JUMP TO REPORT SECTION NOAMS LI R0,11*32+3 ROW 12, COL 4 LI R1,NOSTR NO AMS MESSAGE BL @DISSTR DISPLAY THAT JMP KEYEX JUMP TO EXIT ROUTINE REPORT LI R0,10*32+3 ROW 11, COL 4 LI R1,PGSTR PAGES STRING BL @DISSTR DISPLAY THAT A R2,R0 ADD LENGTH TO POINTER MOV @AMS,R3 GET NUMBER OF PAGES PAST 15 MOV R3,@>835E PUT AT >835E BL @SHWINT SHOW NUMBER ON SCREEN LI R0,12*32+3 ROW 13, COL 4 LI R1,FRMSTR FRAMES STRING BL @DISSTR SHOW THAT A R2,R0 ADD LENGTH CLR R2 CLEAR R2 LI R1,3 SET R1 TO 3 DIV R1,R2 DIVIDE R2-R3 BY 3 AI R2,4 ADD 4 FOR PAGES 4 THRU 15 MOV R2,@>835E QUOTIENT PLUS 4 (FRAMES) TO >835E BL @SHWINT SHOW THAT NUMBER (1/3 OF PAGES NUM + 4= FRAMES) KEYEX BLWP @KSCAN SCAN KEYBOARD LIMI 2 ALLOW INTS LIMI 0 STOP INTS CB @ANYKEY,@STATUS KEY STRUCK? JNE KEYEX IF NOT, REPEAT LWPI GPLWS LOAD GPL WORKSPACE B @>6A BACK TO GPL INTERPRETER * * SUBROUTINES SECTION * * AMSINI SETS AMS CARD TO "POWER-UP" CONDITION * AMSINI LI R12,>1E00 AMS CRU BASE SBO 0 TURN ON AMS LI R1,>FEFF (THIS IS ->0101) LI R0,>4000 START OF MEMORY AMSLP AI R1,>0101 ADD 1 PAGE MOV R1,*R0+ MOVE 2 BYTES TO MEM-MAPPER CI R0,>4020 ALL DONE? JLT AMSLP NO, INIT MORE RT RETURN * * DISSTR DISPLAYS STRING POINTED BY R1 AT SCREEN * LOCATION POINTED TO BY R0 * DISSTR MOVB *R1+,R2 LENGTH BYTE TO R2 JEQ DISX IF ZERO, SKIPIT SRL R2,8 RT JUST BLWP @VMBW WRITE STRING TO SCREEN A R2,R1 ADD LENGTH TO POINTER DISX RT * * FOR SHWINT, FIRST PUT INTEGER AT >835E, * AND POINT R0 AT DESIRED LOCATION * THEN BL @SHWINT * SHWINT BLWP @GPLLNK USE GPLLNK VECTOR DATA >2F7C DATA FOR INT TO STRING MOVB @>8361,R2 LENGTH TO R2 SRL R2,8 RT JUST. MOVB @>8367,R1 ADDR TO R1 SRL R1,8 RT JUST AI R1,>8300 ADD OFFSET BLWP @VMBW WRITE STRING RT * GENERAL PURPOSE GPL LINK * by Doug Warren/Craig Miller * GPLLNK DATA GLNKWS DATA GLINK1 RTNAD DATA XMLRTN GXMLAD DATA >176C DATA >50 GLNKWS EQU $->18 BSS >08 GLINK1 MOV *R11,@GR4 MOV *R14+,@GR6 MOV @XTAB27,R12 MOV R9,@XTAB27 LWPI GPLWS BL *R4 MOV @GXMLAD,@>8302(R4) INCT @STKPNT B @LDGADD XMLRTN MOV @GETSTK,R4 BL *R4 LWPI GLNKWS MOV R12,@XTAB27 RTWP * * DATA SECTION * WS BSS 32 OUR REGISTERS AMS DATA 0 PAGES BEYOND 15 NOSTR BYTE 19 TEXT 'NO AMS CARD PRESENT' PGSTR BYTE 14 TEXT 'PAGES FOUND = ' FRMSTR BYTE 9 TEXT 'FRAMES = ' ANYKEY BYTE >20 END * * END OF COMPLETE PROGRAM * * PART TWO OF SIDEBAR - A "SNIPPET" * * SUBROUTINE SETFRM (FROM AMS VIDEO TITLER) * ON ENTRY, R3 CONTAINS THE CURRENT FRAME NUMBER (1 THRU XX) * WHERE XX CAN BE 9 (128K CARD), 20 (256K CARD), OR 41 (512K CARD) * PAGE NUMBERS START WITH 0, SO FOR EXAMPLE ON A 256K CARD, PAGES * ARE NUMBERS 0 THRU 63, FOR A TOTAL OF 64 PAGES * * THE PROGRAM "KNOWS" HOW MANY FRAMES ARE AVAILABLE, AND * WON'T USE THIS SUBROUTINE BEYOND THE AVAILABLE FRAMES. * SETFRM MOV R3,R1 COPY CURRENT FRAME # TO R1 MPY @THREE,R3 MULTIPLY R3 BY 3 INC R4 ADD 1 TO PRODUCT IN R4 (PAGE NUMBER ON AMS = 4 THRU YY) * YY IS THE HIGHEST PAGE -2 SWPB R4 SWAP TO LEFT BYTE COC @ONEWD,R1 CHECK CURRENT FRAME FOR ODD/EVEN JNE SETEVN IF NOT 1 IN LSB, EVEN SETODD LI R8,>4014 MAP FOR >A000 LI R1,>A000 SET R1=>A000 JMP SETPGS JUMP SETEVN LI R8,>401A MAP FOR >D000 LI R1,>D000 SET R1=>D000 SETPGS LI R12,>1E00 AMS CRU ADDR SBO 0 TURN ON CARD SBO 1 TURN ON MAPPER LI R5,3 THREE WRITES TO MAKE (3 PAGES PER FRAME) SETLP MOV R4,*R8+ SET CURRENT PAGE AND INCT R8 AI R4,>100 NEXT PAGE DEC R5 DEC COUNT JNE SETLP RPT IF NOT 0 SBZ 0 TURN OFF CARD MEMORY (>4000) * THE MAPPER STAYS ON RT RETURN * UPON RETURN, R1 IS USED TO DETERMINE WHERE THE FRAME IS SENT OR GOTTEN FROM * DEPENDING WHETHER WE'RE WRITING OR READING A FRAME * * END OF PART 2 OF SIDEBAR ============================================================================ DTIHM005 Corcomp Memory Expansion Unit. This device uses a TMS4500 for Memory Refresh. (There is no 9901 on the card as a previous version of this documented stated.) CRU Bit Purpose 0 DSR Rom Enable 1 Ram Disable 2 Bank 0 3 Second 256K 4 Rom Page 6 Bank 1 \ 10 Bank 2 \ 14 Bank 3 \ Pages 18 Bank 4 / 22 Bank 5 / 26 Bank 6 / 30 Bank 7 / 32 Reset=1 Each bank fills the entire 32K area (>2000-3FFF,>A000-FFFF). Only one of the CRU bank bits should be active (=1) at any given time. CRU bit 1 will disable all the RAM on the memory card. By disabling the RAM, Corcomp was able to support a second memory card. The design of the Corcomp memory prevents most track copiers from working. This is undoubtedly because the Corcomp memory affects the bus timing. ========================================================================== DTIHM006 WHT Keyboard Interface Specifications for TI 99/4a AT Keyboard interface and ROM upgrade Copyright 1993-96 Western Horizon Technologies CRU DEFINITIONS: CRU Base: >0400 System Occupies >0000 to >03FF due to partial decode of 9901. Output Bits: 0 1=Turn On 8251A USART at base address >4000 1 1=Disable ROM/RAM on card, 0=ENABLE (enabled at power up) 2 1=RAM in >0000 to >2000 space, 0=EPROM (EPROM on power up) 3 spare - NOT Connected 4 Enable 8251A character in receive buffer interrupt to system 5 8251A RESET 6 1=Set system RESET line* (Causes a hardware reset to occur, should be activated by a CTL-ALT-DEL) 7 1=Cause a NMI* (LOAD Interrupt, should be activated by a SHIFT-PRINT SCREEN) 8 EPROM Extended address bit 0 (LSB) 9 EPROM Extended address bit 1 10 EPROM Extended address bit 2 (MSB) 11 EPROM Extended address bit 3 (Spare) 12 SRAM Extended address bit 0 (LSB) 13 SRAM Extended address bit 1 14 SRAM Extended address bit 2 (MSB) 15 SRAM Extended address bit 3 (Spare) Input Bits: Bit 0-3 Dip Switch Positions 1-4 If switch is OFF, Bit=1 Bit 4 8251A Sync/Break detect Bit 5 8251A Transmitter ready, 8251A is ready to accept data Bit 6 8251A Transmitter empty, 8251A Has sent data if=1 Bit 7 Character in 8251A receive buffer REGISTER DEFINITIONS: Registers at >4000 and >4002 only available when CRU BIT 0 is TRUE Registers at >8000 and >8002 are always available. This is the location of the memory mapper registers on the Myarc Geneve 9640. Registers are only partially decoded to a 128 word block. They physically occupy the >4000->4100 and >8000->8100 areas. PAD RAM begins at >8300 Read Registers >4000 OR 8251A Data from serial bus >8000 >4002 OR 8251A Status Register >8002 Write Registers >4000 OR 8251A Send data >8000 >4002 OR 8251A Control Register >8002 * Not supported on initial board revision =========================================================================== DTIHM007 More on the WHT Keyboard Interface: I can get you the information on accessing the memory in the WHT keyboard. It is all done with CRU instructions. The base CRU address for the AT keyboard interface is located at >400. The memory is banked in at addresses 0000-1FFF (8K) and replaces the console ROM. You can swap between EPROM and optional RAM on the interface by setting bit 2. Setting this bit to 0 selects the EPROM. Setting this bit to 1 selects the optional RAM. There are 8 banks of ROM and 8 banks of RAM. The bank selection is controlled by bits 12-15 for RAM and 8-11 for ROM. You may notice that there are more bits than are needed to select 8 banks. Don O'Neil left room for future expansion to double the amount of memory on the card. Anyway, lets say you want to select bank 2 of the RAM. Your code would look something like this - LI R12,>400 SBZ 2 Turn on the RAM LI R12,>400+24 LI R1,>0200 Select RAM bank LDCR R1,4 When you are done, you want to enable bank 0 of the EPROM again LI R12,>400 SBO 2 Turn on EPROM LI R12,>400+16 CLR R1 Select ROM bank 0 LDCR R1,4 -- David Nieters Dave.Nieters@dtc.fingerhut.com Fingerhut Companies ============================================================================== DTIHM008 Using the MBP This MBP is a memory mapped device. It maps into the 1K Block that is reserved for sound >8400->87FF. It uses National Semiconductor ADC&Real Time clock. ONLY EVEN NUMBERED ADDRESSES ARE USED!! The clock and date Function. Basic Address Assembler EQU Definition -31168 >8640 Thousands Sec - 66 >8642 Tens & Hund Sec. - 64 >8644 Seconds - 62 >8646 Minutes - 60 >8648 Hours - 58 >864A Day of Week - 56 >864C Date - 54 >864E Month With a Geneve in GPL mode you can access the clock and date function at the same addresses. In either GPL or MDOS mode, you can map physical page >BC to any logical page and access the clock and date function at offset >0640 in the 8K page. ============================================================================== DTIHM009 Super Cartridge: This was the name of the orginal project published in Micropendium. It consisted of an E/A module, modified to add 8K of ram to the cartridge port - this RAM was backed up. In addition to giving programmers 8K of additional RAM for assembly code, for the first time programmers could actually create their own cartridges - so that with the cartridge inserted and the machine powered on, their software would now appear as a menu option under 1. Basic. Here is a snippet of code by David R. Romer from his July '85 article in Micropendium. *************************** * Super Cart Test Program * *************************** DEF TEST Define label TEST as program name AORG >6000 absolute code starting at >6000 DATA >AA01 start of CARTRIDGE HEADER, value >AA01 DATA >0 must be at address >6000 DATA >0 DATA >MNULNK pointer to first menu table entry DATA >0 DATA >0 MNULNK DATA >0 2st menu table entry, DATA 0=single entry. DATA ENTRY pointer to start of program BYTE >09 length of text to be displayed on menu scrn TEXT 'MENU TEST' actual menu text to be displayed ENTRY B @TEST branch to start of program **************************** WS BSS 32 MASK DATA >4000 MSG TEXT 'MENU TEST PROGRAM' TEST LWPI WS LI R0,263 scrn location for display LI R1,MSG pointer to text to be displayed LI R2,17 length of text BL @VMBW ***************************** LI R1,>0A delay loop while text is on screen LOOP LI R0,>FFFF LOOP1 DEC R0 JNE LOOP1 DEC R1 JNE LOOP ***************************** LWPI >83E0 load GPL workspace BLWP @>0000 brach to color bar screen ***************************** VMBW SOC @MASK,R0 stand alone VDP multiple byte write routine SWPB R0 MOVB R0,@>8C02 SWPB R0 MOVB R0,@>8C02 NOP WLP MOVB *R1+,@>8C00 DEC R2 JNE WLP B *R11 END ========================================================================== DTIHM010 DataBioTics Super Space II. The Super Space II takes the design of the orginal Super Cart much further by giving the program 32K that can be banked in 8K pages at the >6000 address space. I have a DataBioTics Super Space II! Two, actually! Love 'em! Banks are selected by writing a bit pattern to CRU address >0800: Bank # Value 0 2 1 8 2 >20 3 >80 I don't know why this has to be a 16-bit transfer, but that's what the books says. The example is the following subroutine, with the bank number (0, 1, 2, or 3) in R0: BNKSW LI R12,>0800 Set CRU address LI R1,2 Load Shift Bit SLA R0,1 Align Bank Number JEQ BNKS1 Skip shift if Bank 0 SLA R1,0 Align Shift Bit BNKS1 LDCR R1,0 Switch Banks SRL R0,1 Restore Bank Number (optional) RT (I'm not sure they're quite correct. I thought you couldn't shift R0!) But there you go! Regards, -- *** David Ormand ************ Southwest 99ers *** *** dlormand@aztec.asu.edu ** Tucson, Arizona *** ***************************** TMS9900 Lives! **** ============================================================================- DTIHM011 33210 17JUL92-1918 General Information RE: TI CPU bug??? (Re: Msg 33209) From: JHWHITE To: JPLESLIE David: The DECrement instruction actually adds ">FFFF" to the value being decremented. The carry is set whenever the resulting value would be greater than >FFFF. The only time the resulting value is not greater than >FFFF is when the value being decremented is >0000. Some bitwise arithmetic shows what happens: DEC >8000 = b1000 0000 0000 0000 + b1111 1111 1111 1111 = >FFFF -------------------- C=1 b0111 1111 1111 1111 = >7FFF DEC >FFFF = b1111 1111 1111 1111 + b1111 1111 1111 1111 = >FFFF -------------------- C=1 b1111 1111 1111 1110 = >FFFE DEC >0000 = b0000 0000 0000 0000 + b1111 1111 1111 1111 = >FFFF -------------------- C=0 b1111 1111 1111 1111 = >FFFF Adding >FFFF, which can be thought of as -1 in two-complement form, is what the 9900 does when it DECrements. Jeff White p.s.: That rule for carry does not mean when the value of bit 0 changes, but when the addition of >FFFF to the value results in a carry value of 1 out of bit 0. If the value in bit 0 changing caused a status bit to change, it would be the OVerflow bit, not the carry bit. -*- ============================================================================= DTIHM012 35301 22OCT92-0313 TI ECHO RE: clock speed? (Re: Msg 35287) From: JHWHITE To: ILLUSIONIST The 99/4A runs at 3 MHz with 8192 bytes ROM and 256 bytes RAM at 0 wait state, and the rest of memory or memory-mapped devices at 4 wait states. At 0 wait state, a full (16-bit) word is moved across the CPU data bus in two clock cycles, which makes a theoretical maximum through-put of 1.5 Mwords/sec. Of course, with 4 wait state memory, that takes the theoretical maximum through-put down to 0.5 Mwords/sec. Then take into account that the 9900 bus is only active about 25% of the time (because it is not pipelined like the 9995 or 99000). Jeff White -*- ============================================================================= DTIHM013 What's wrong with the TI-99/4(a)? It can be summed up in four words - "ninety-nine eighty five." No, this is not the price your local discount store "blew" them out at in 1984.....or maybe it was, but. I am referring to the TMS9985. This was the CPU that TI originally planned to have in the 99/4. Due to technical difficulties, the TMS9985 was never produced. That forced TI to use the more expensive 9900 in the 99/4, instead of the less expensive 9985. The TMS9985 is the father of the 9995, just as the 99000 is the son of the 9900. Let's review some of the highlights of the 9995. o Has an onboard cache of 256 bytes. o Has an 8-bit data bus. o Utilizes only one dedicated external interrupt level besides Reset. These are all "features" that the 9995 and 9985 share. Highlights of the 9900. o Has a 16-bit data bus to all memory. o Has 15 external prioritized interrupts levels besides Reset. Now, let's say for a minute you had a system designed for a TMS9985 but you where suddenly forced to use a 9900. Most of us would go back to the drawing board and create a vastly more powerful computer, but the engineers at TI were under presure to get something done quickly with out re-engineering the entire computer system.... What would you do? o Tie interrupt pins such that only one external interrupt level was possible. o You would probably implement the 256 bytes of onboard ram as 256 bytes of static ram on the 16-bit bus to simulate the on board cache, but would leave the rest of the system access as 8-bit reads ( done twice ). Does all of this sound familiar? These considerations have had one major impact. If TI had implemented the 9900 like it had been designed, anyone building a 4(a) compatible would have been forced to use the 99000 as an upgrade processor. Had to redesign the 99/4(a) to utilize the 9900 to it full capabilities, we would have had a vastly superior computer. Minicomputer class capabilities! While you can cripple a 9900 or a 99000 to act like a 9985 or 9995, you can not make the reverse happen..... The End L.D.O.M. 12.6.96 =========================================================================== DTIHM014 Highlights of the 99105A By Dan H. Eicher As you all know the 99/4(A) uses the 9900 CPU. The Geneve use the 9995. Well in the not to distance future you may have a new choice of what CPU you want to use in your 99/4(A). Don O'Neil and Gary Bowser are working on a new product called the "Accelerator" for the 99/4(A) community! Rather than just bring the 4(A) up to the same microprocessor that the Geneve uses they decided to surpass it. The 99105A is a third generation 9900 CPU. The first generation consisted of the 99xx's (used in the 99/4(a), the second generation consisted of the 9995 (used in the geneve) and the third generation consists of the 99105A and 99110 (The 99110 is no longer produced by TI). Below shows the pin assignments and definitions of the 99105A. ___ ___ WE/IOCLK =1 U = MEM As you can see the TMS99105A is a RD = = BST1 40 pin dip package, unlike the 9900 RESET = = BST2 which is a 64 pin wide body dip chip. APP = = BST3 HOLD = = XTAL1/CLKIN The 99105A is only sold in high VSS = = XTAL2 reliability specifications. Which READY = = CLKOUT means it comes in a ceramic package INTREQ = = Vss and the leads of the chip are gold NMI = = ALATCH plated. IC0 = = PSEL/D15/OUT IC1 = = A14/D14 For further specifications you can IC2 = = A13/D13 order TI part #MP009, from 1-800- IC3 = = A12/D12 123-1234. This data book is called R/W = = A11/D11 the TMS99015A and TMS99110A Vcc = = A10/D10 Preliminary Data Manual. You may have A0/D0/IN = = A9/D9 to be persistant that you know the A1/D1 = = A8/D8 data books is available and the TI A2/D2 = = A7/D7 still makes the chip, because TI A3/D3 = = A6/D6 doesn't like to discuss 99xx based A4/D4 = 21= A5/D5 chips anymore. ------- Whats new in the 99105A? * Pipe Line Architecture * Directly accessable 256K bytes of memory * 84-Instruction superset of the TMS9900 - Signed multiply and divide - Long word (32-bit) shift, add, subtract - Load status register, load workspace pointer - Stack support - branch and push link, branch indirect - Multiprocessor support - test, test and clear, test and set * Privileged mode * Macrostore(1) emulation of user-defined instructions * Arithmetic falut interrupt * Illegal instruction interrupt * Multiprocessor system interlock signal * Attached processor interface * N-channel silicon-gate SMOS technology Lets look at some of these new features: 1. Pipe Line Architecture. If this chip had nothing more new to add to the 4(A) environment then this, this would be enough. Heres how pipe lining works. This example is from the book "The 99000 Microprocessor" by Avtar Singh. Lets take the assember instructions: A R0,R1. Step Function Type 1 Fetch instruction Memory 2 Decode instruction Internal 3 Fetch source operand Memory 4 Fetch destination operand Memory 5 Add operands Internal 6 Write resule to destination Memory ( Register to register addition sequence ) Instruction fetch Decode Source fetch Destination fetch Process Instruction fetch Write Decode Source Fetch Destination fetch Proces Instruction Fetch Write Decode Source Fetch \_____________________________ _____________________________________/ V Prefetch Mechanism " Looking at the instruction sequence, we see that during the two internal operations the system bus to external memory is not busy. To make more efficient use of the system bus, the 99000 is implemented with an intelligent instruction prefetch mechanism. With the mechanism, the execution of consecutive instructions is overlappped. This feature is also known as pipelining. Notice that while the first instruction is being processed, the 99000 initiates an instruction acquisition memroy bus cycle to fetch the next instruction. This second instruction is decoded while the results from the first instruction are being written to memory. In this way, we see that during each of the six steps of the addition instruction, the system bus is always in use." As you can imagine this improves system through put dramatically with out running the system any faster. The 99000 prefetch is intellegent. On the 99xx your program counter gets an instruction and increments the program counter (PC), well if the instruction that was just fetched happens to be a jump or branch instruction then the microprocessor just turns around and updates the program counter. With an intellegent prefetch the system "knows" if the instruction just fetched is a jump or branch if it is the system updates the PC with the next memory location to be used, NOT the next seqentail address. 2. More memory (up to 256K bytes). Heres what the memory map looks like in extended mode. The way this is done is by using PSEL and (BST1- BST3) to provide extended address lines. MAIN MEMORY SPACE | ------------------------------- | | INSTRUCTION DATA SEGMENT SEGMENT (64K) (64K) | | ------------ ------------ | | | | PAGE 0 PAGE 1 PAGE 0 PAGE 1 (64K) (64K) (64K) (64K) \_____________________ ________________________/ V 256K BYTES Of course on a standard 4(A) you would need a special memory board to take advantage of this much memory. (Don is working on a way to fix you up with a new memory board also). 3. Macrostore An entire book could be deducated to the subject of Macrostore alone. In brief, macrostore is a way to add to the native instruction set of the 99000. Lets say you need an op-code that will give you the square root of a number. Define it! Then in your source code you can have an instruction like SQRT R1 or SQRT R1,R2! TI had one version of the 99000 that had the entire UCSD pascal kernal all in Macrostore code. The 99110A had floating point instructions built into its macrostore. This eliminated the need to have a seperate numeric coprocessor. 4. Privileged Mode. When privileged mode of operation is selected two levels of operators are created, one designated the user and the other the supervisor. Certain instructions are then barred for use from the users programs. These operations include SBO, SBZ, LDCR, LIMI, RSET, LST, RTWP, IDLE, CKON, CKOF, LREX LDS, LDD. All of these op codes modify settings that could disturb the running of other programs in a multiuser/multitasking environment. So in short this mode of operation was designed to facilitate the development of multiuser/multitasking system software. 5. Attached processor interface + Attached computer interface. The 99xxx family has the capability to "attach" either another computer or processor to its self. This is similar to the 8086 family of processors ability to use an 8087. Although with the ability to have special floating point opcodes in macro store a numeric co-processor is not need. (For detailed information on a 99110 V.S. an 8086 with a co-processor see..... Here is the evaluation sequence that the 99xxx goes through when it goes to execute the next op code from a program: If it is a stndard op code then "Execute standard MicroCode" Else If (*) an attached computer then "Invoke and continue" Else If (*) an attached computer then "Invoke and wait" Else If it is an opcode defined in Macrostore then "Invoke emulation" Else If it is an opcode defined in main memory the "Invoke emulation" Else Handle as an illegal opcode. * it is an opcode recognised by.. 6. Op Code Compression While not highlighted as a feature 99xxx family another interesting aspect to its design is the way op-codes are scrunched in memory. This allows much more efficient use of the pipeline fetches. Who to contact about availability: Bud Mills 166 Dartmouth Drive Toledo, OH 43614-2911 (419)-385-5946 Tenative price is two hundred and fifty US dollars. References: Singh, Avtar, "The 99000 Microprocessor". Englewood Cliffs, N.J.: Prentice-Hall, Inc, 1984. ISBN 0-13-622846-1 Texas Instruments Incorporated, TMS 99105A and TMS99110A 16-Bit Microprocessors Preliminary Data Manual. Houston:Texas Instruments INC, Nov. 1982 L.D.O.M. 12.6.96 ========================================================================== DTIHM015 #1 5-JUL-1992 18:59:42.60 MAIL From: BOS::JHWHITE To: EICHER CC: Subj: bugs, bugs, and more bugs Dan: I've been looking over the console ROM source code and have located the main problem with the interrupt routine. Two instructions are reversed. The console ROM has the following: 0918 020C LI R12,>0F00 loads CRU base with >0F00 091A 0F00 to start CRU scan of DSR peripherals 091C 1D01 SBO 1 enables meaningless bit >0F02 The above can be seen (in slightly different fashion) on page 29 of TI Intern. What should be there is the reverse, which could solve lots of trouble: 0918 1D01 SBO 1 clears External Interrupt and re-enables 091A 020C LI R12,>0F00 loads CRU base with >0F00 091C 0F00 to start CRU scan of DSR peripherals So just dump a working console ROM, search for 020F1D in the even bank, and replace with 1D020F. Replace 0C0001 in the odd bank with 010C00. If you want, I can send you fixed ROM files with correct CRC values at the end. With the TI RS232 DSR, TI compounded the interrupt problem by (re-)enabling the RS232 interrupt even if the the RS232 was not the initiating peripheral. The fix is a one byte change. An excerpt from TECHNICAL DRIVE (pp32,33) shows the problem code: 40EA 1F10 TB >10 ** Test for character received 40EC 1310 JEQ $+>22 >410E ** Yes?, then jump 40EE 1F1F TB >1F ** Data set change, timer interrupt ** transmitter interrupt? 40F0 1632 JNE $+>66 >4156 ** No?, then jump 40F2 C306 MOV R6,R12 ** Restore CRU address .... 4156 1D12 SBO >12 ** Set receiver interrupt enable 4158 C306 MOV R6,R12 ** Restore CRU 415A 1E07 SBZ >07 ** Turn off LED 415C 0455 B *R5 ** Return Any interrupt that is not cleared before the CRU peripheral scan gets to the RS232 will cause the RS232 interrupt to turn on. The console ROM interrupt bug (for which I gave the fix) causes ALL peripherals to be checked for interrupts unless a DSR clears the External Interrupt with the equilavent of: CLR R12; SBO 1. An example of the problem is the Digit AVPC and the TI RS232, which share the External Interrupt line. The RS232 is normally at CRU>1300 and the AVPC is at CRU>1400. The VDP interrupt is active on the External Interrupt line. The console CRU peripheral scan finds the RS232 interrupt routine first, which we'll assume is supposed to be inactive. The RS232 interrupt routine tests the CRU bits on the UART's (9902A's), and falls through to the instruction at >40F0, which determines that there is no active RS232 interrupt. Then it jumps to the instruction at >4156 which turns ON the RS232 interrupt (BAD MOVE) and is followed by the exit back to the CRU peripheral scan. No more RS232 interrupt routines are available, so the CRU peripheral scan goes to the next peripheral, at CRU>1400 -- the Digit AVPC. The AVPC interrupt routine should then execute properly (though Digit and OPA DSR's are somewhat lacking, either failing to test conditions or leaving the interrupt hanging). For the sake of this attack on TI code, I'll leave Digit and OPA out of it. Just assume that the AVPC DSR does everything it should as if the TI code was not buggy. The first VDP interrupt goes as planned. However, now the RS232 port 2 interrupt is enabled whether it was supposed to be or not. And the console ROM did not clear the External Interrupt (the bigger problem). Consider the failure to clear the External Interrupt again. If that line is never reset, the first VDP interrupt causes the interrupt routine to be active each time interrupts are turned on whether an actual interrupt occurs or not. The RS232 mis-activated interrupt only becomes a problem when the RS232 port 2 receive buffer gets filled. Normally, RS232 interrupts are only activated by the RS232 Circular Buffer routine used by TE's. This too can cause trouble if the AVPC is installed without a circumventing DSR. But the bug in the RS232 DSR also means that TE's that do polling rather than use interrupts will cause problems with the AVPC installed. Now to the RS232 fix. If no RS232 interrupt is active, the RS232 interrupt routine should not turn them on. This means that the instruction at >40F0 should be changed to jump to >4158 instead of >4156: 40F0 1633 JNE $+>68 >4158 40F2 C306 MOV R6,R12 ... 4156 1D12 SBO >12 4158 C306 MOV R6,R12 415A 1E07 SBZ >07 415C 0455 B *R5 Thus, if you dump your RS232 EPROM and find >32 at byte offset >00F1, replace it with >33. I'll hold off on sending you a workable AVPC DSR until you tell me which of the above fixes you implement. Fixing both the console ROM and RS232 DSR is the best alternative. Jeff White ============================================================================ DTIHM016 Setting up user interupt routines. by Jeff White 37476 13FEB93-2100 General Information RE: CLIPBOARD99 (Re: Msg 37475) From: JHWHITE To: EICHER Dan: Simply daisy-chain your interrupt routine over any already loaded at address >83C4. Check the value at >83C4 upon loading your interrupt routine. Whatever its value, you should save it in your routine. Now copy the start address of your interrupt routine to >83C4. At the end of your interrupt routine, check the address you saved. If not zero, branch to it. Otherwise return. Jeff p.s.: This is the correct procedure for any VDP interrupt driven routine. You save the address at >83C4 into the new interrupt routine before putting the start address of the new routine at >83C4. Then you check the value you saved at the end of your interrupt routine, and if equal, return, else branch to the previous interrupt in the chain. -*- 37495 14FEB93-2009 General Information RE: CLIPBOARD99 (Re: Msg 37484) From: JHWHITE To: JDELEKTO Joe, you are quite right that daisy-chaining interrupt routines slows things down. I am aware of means to speed things up. Console sprite motion, sound, and quit key interrupts can be disabled by simply make bit 0 (MSbit) of the interrupt flag byte at >83C2 equal to 1. The user interrupt routine can still be active, and it can use the interrupt flag byte to flag various interrupt routines. In fact, the byte at >83C3 is NEVER used by the console (though some Dijit AVPC systems use it), so you can have an interrupt flag word. The user interrupt routine(s) can control sprite motion any way you wish, and the motion information can be in CPU memory instead of VDP memory if the routine is written to handle it. Sounds lists are not limited to VDP or GROM memory either. Even a fast keyscan can run off the interrupt if you desire. If you decide to use the the console interrupt routines (bit 0 of byte >83C2 equal to 0), there are still the 12 lsbits of the WORD at >83C2 to flag user interrupt routines. You can have more than 12 if you are content to let the 4 msbits of byte >83C2 serve dual purpose (no console ROM-driven sprite motion if byte >837A is >00, no console ROM-driven sound if byte >83CE is >00, no quit key if not pressed). Or if you are really clever, you can use all 16 bits of the word at >83C2 to flag user interrupt routines by reversing polarity. I.e., if any of the 4 msbits of word >83C2 is 1, then the related user interrupt routine is executed while the related console ROM-driven interrupts are not. The 12 lsbits of word >83C2 can flag up to 24 interrupt routines (if both bit values enable). Of course, you could redefine the word at >83C2 to work differently than the console usage. When bit 0 is 0, the 12 lsbits can mark 4096 locations in an interrupt vector table. When bit 0 is 1, the 15 lsbits can mark 32768 locations in an interrupt vector table. With the AMS/AEMS or 4A Memex systems, you are only limited by your imagination (and how much of a slowdown you can stand). If you want to execute 32768 interrupt routines in rote, make bit 1 of >83C2 equal to 1 and load user-interrupt vector >83C4 with the address of the user-interrupt handler. Use the 5 msbits of the 15 lsbits of >83C2 to mark a page of AMS memory, and the 10 lsbits of the 15 lsbits of >83C2 to mark an offset in that page. If you want BLWP vectors, two words will have to be marked by each of the 10 lsbits, or the entire 4K of each of the low 32 pages could be used. However, the two words could be used as a pseudo-BLWP vector. The 5 msbits of each word in the pseudo-BLWP vector could be used to mark which pages of the next 32 pages (eg, 32-63) the routine and its workspace use. The 11 lsbits of each vector address would mark the word offset. If you wanted, the workspace pointer of the pseudo-BLWP vector could point to a page in 32-63, and the program counter of the pseudo-BLWP vector could point to a page in 64-95. Of course, each time the user-interrupt handler is called, the value in the word at >83C2 is incremented and the msbit is set to 1 to prevent console ROM-driven interrupts from taking place. Though if console ROM-driven interrupts are needed, the use-interrupt handler can still have up to 4096 interrupt routines handled in rote. Just use bits 4 and 5 of word >83C2 to mark 4 pages of AMS memory for the 4096 pseudo-BLWP vectors. The 10 lsbits of >83C2 would be the vector offset in the page. This all seems quite ridiculously esoteric, doesn't it? However, you may now be thinking about what I am about to describe. A VDP-interrupt-driven OS -- VIDOS for short -- that puts the OS opcode number in the up to 15 (12 if you want to use console sprite motion, sound lists, and quit) lsbits of >83C2. The user-interrupt handler now becomes the VIDOS opcode handler with a few simple modifications. Say we use only the 12 lsbits of >83C2. A value of >000 tells the VIDOS to run its interrupt service routine. Values >001-FFF can be opcodes that do something. The 4 pages marked by the 2 msbits would contain the pseudo-BLWP vectors just as I described above. Parameters can be passed to the VIDOS opcode in CPU PAD, VDP PAD, or some page mappable to the 32K memory. In fact, you could even do a GPL interpreter with this VIDOS. Say that GPL opcodes >00-FF are passed to VIDOS as >C00-CFF. This would put the pseudo-BLWP vectors in the 4th page (11b), and the opcode marks the right vector. That should be enough food for thought right now. Sure, the interrupt routine of the console ROM is not that great. But some great things can be done with it and enough memory. Jeff White p.s.: I had another message describing another method to handle user interrupts, but I accidentally deleted it. -*- ============================================================================ DTIHM17 Interupts by Jim Ness INTERRUPT ME! ------------- How to use (and abuse) your computer's interrupt capabilities. -By Jim Ness ---------------------------------------- October, 1984 ************* Whether you program in assembly language on a TI99/4A computer, or most any other, you probably have come across a few references to "Interrupt Handling." If you react to the unknown the way I do, you probably skipped it, because you didn't need to know what it was all about. Once I had some of the basics of assembly language programming down, I came back to it. I had just seen an int- errupt driven clock/timer program, and decided it was time to see what made it tick (sorry, it was irresistable). In this first chapter, we'll see what interrupts are all about. Why are they necessary, when do they come in handy, and a beginning on the do's and dont's of programming with interrupts. ***** The beast we all call "Computer" is a narrow minded individual. It does what you tell it and does not pay attention to anything else. From the time you turn the power on, it is performing a task. In the case of the TI99/4A, a "power- up" routine is run, checking all the closets and corners to see what periph- erals are connected, and then displaying the color bar screen, and waiting for you to press any key. The problem with single-mindedness is that there are always a couple of things you would like to be able to do at any point in a program. For instance, you would like to be able to "QUIT" at any time. But if your program is busy adding numbers or printing text or displaying graphics, it doesn't care about your de- sire to "QUIT." It's busy. The solution is to have a timer stop the program on a regular schedule, and check to see if there are alternate tasks to perform, such as paying atten- tion to the goof trying to "QUIT." The TI99/4A, and all other modern computers have that capability built in to the operating system. Traditionally it is used to implement internal functions such as system reset or peripheral data transfers (disk or cassette). You don't want your program to move along before your disk drive is finished transferring data, for instance. But in the case of the ole TI99/4A, there is provision made for the user to add his/her own interrupt. There is an address located in the onboard CPU RAM which is checked 60 times per second. If there is a memory address "poked" in- to here, the program will branch to that address and perform what ever task is placed there. So, you could have a keyboard scan routine there to check for a "QUIT" command. Or a screen color or character change command. Or any pro- gram your little heart desires. ******** If you have read up on interrupts in the TI99/4A Editor/Assembler manual, you will have seen their mention of using up all the processor's time handling the interrupts. THIS is the big pitfall. Suppose you design a little routine to re-define each of the characters and the screen color, but you don't pay too much attention to the efficiency of your program. You may end up with quite a long routine. Say your routine takes 150 ms to perform, more than a tenth of a sec- ond. Remember that an interrupt routine will be called each time 1/60th of a second has passed. So here is the resulting time-frame: - 17 ms - The program - 150 ms - The interrupt - 17 ms - The program - 150 ms - The interrupt - 17 ms - The program (**etc**) You can see that the interrupt routine will run in its entirety each time, but the main program runs in tiny jerks and has to keep stopping for the interrupt routine. The result is that the main program ends up running very sllooowwww. And you have slowed it down just so you could have your favorite characters and screen color. The point is that if you want to use an interrupt routine, it must be very short and efficient. It must do one very important thing and quickly go back to the main program. The ideal interrupt would finish up in the 1/60 second time slot that the clock allows. If it took exactly 1/60 (17ms) it would share time on a 50/50 basis with the main program,so even that is a little too long. It is hard to figure if your interrupt program will be too long, but here is a rule of thumb to follow: Make yoursource listing no more than 20 lines long. The resulting program, after assembly, regardless of what it is, will be short enough. Your homework question: Which method of file access would be acceptable for use in an interrupt rou- tine? (A) Disk Drive (B) Cassette (C) 128k card (D) Minimemory Well, if you have been paying attention, you know that none of the above is usable. Because of the time restrictions that must be followed, you just can't wait for data to be transferred, even at the speed that the MMM and 128k 'ram disk provides. One question that has come up is where can we 'poke' the starting address of our routine so that it will run. Per the Editor/Assembler manual, the address of the user defined interrupt routine must be put into >83C4. The simplest way to do this is to use an 'AORG' statement near the end of the program, to force the loader to move to that memory address, and then use a 'DATA' statement to fill that address with the beginning address of your routine. Check the ex- amples below to see what I mean. Through the magic of TI-EXTENDED BASIC file handling routines, I am appending my DV80 source code files to this text, so you can see the examples. If you do not wish to take the time to go through them, just key "A" to abort this section on the BBS, and check back later, if you want. The source codes shown are in DV80 format and sometimes exceed the 40 col- umns on your screen, so you will see a few wraparounds. One way to solve the problem is to save what appears and reread it with the Editor/Assembler in edit mode, or with TI-Writer. The two programs shown are SETCOLOR & SETCHAR, both of which appeared in the D/L section of this BBS. Setcolor will change the color of screen and chars in Xbasic, and Setchar adds a real lower case charset. Each of them override the Xbasic interpreter's defaults. --------- *************************** * * * ASSEMBLY LANGUAGE * * ROUTINE TO CHANGE * * THE TEXT AND SCREEN * * COLORS IN X-BASIC * * FOR PROGRAMMING * * * * BY LARRY BENTLEY * * 9/29/84 * * * *************************** DEF COLOR * * SET EQUATES FOR XBASIC VMBW EQU >2024 VWTR EQU >2030 C DATA >F4F4,>F4F4,>F4F4,>F4F4 * SET 8 BYTES ASIDE TO LOAD COLOR LI R0,>07F4 * CHAR COLORS. ALSO LOAD VDP BLWP @VWTR * R1 WITH SCREEN BKGRD COLOR LI R0,2048 * START LOADING CHARSET COL- LI R1,C * ORS LI R2,8 BLWP @VMBW LI R0,2056 BLWP @VMBW LI R0,2064 BLWP @VMBW LI R0,2072 BLWP @VMBW B *R11 * RETURN TO MAIN ROUTINE AORG >83C4 * DURING LOADING, MOVE TO >83C4 DATA COLOR * PUT THE ADDRESS REPRESENTED BY END * COLOR INTO >83C4 *--------------------------------------------------* ********************************** * THIS ASSEMBLY LANGUAGE ROUTINE * * CHANGES THE DEFAULT LOWER CASE * * CHARACTERS TO TRUE LOWER CASE, * * INSTEAD OF JUST SMALL CAPS. * * -BY JIM NESS, OCT. '84 * ********************************** DEF LOWCAS VMBW EQU >2024 CHARS DATA >0000,>0070,>0838,>4874 ; a DATA >0040,>4078,>4444,>4478 ; b DATA >0000,>0038,>4440,>4438 ; c DATA >0004,>043C,>4444,>443C ; d DATA >0000,>0038,>447C,>403C ; e DATA >0018,>2420,>7020,>2020 ; f DATA >0000,>0438,>4438,>047C ; g DATA >0040,>4078,>4444,>4444 ; h DATA >0010,>0030,>1010,>1038 ; i DATA >0008,>0018,>0808,>4830 ; j DATA >0040,>4048,>5070,>4844 ; k DATA >0030,>1010,>1010,>1038 ; l DATA >0000,>0078,>5454,>5454 ; m DATA >0000,>0058,>2424,>2424 ; n DATA >0000,>0038,>4444,>4438 ; o DATA >0000,>0078,>4478,>4040 ; p DATA >0000,>0038,>4454,>4834 ; q DATA >0000,>0058,>6440,>4040 ; r DATA >0000,>003C,>4038,>0478 ; s DATA >0010,>1038,>1010,>1408 ; t DATA >0000,>0048,>4848,>4824 ; u DATA >0000,>0044,>4428,>2810 ; v DATA >0000,>0044,>5454,>5424 ; w DATA >0000,>0044,>2810,>2844 ; x DATA >0000,>0044,>2418,>1060 ; y DATA >0000,>007C,>0810,>207C ; z LOWCAS LI R0,>0608 * START AT CHR 97, VDP ADDR >0608 LI R1,CHARS * REFER TO ABOVE NEW CHARS LI R2,208 * 208 NEW BYTES BLWP @VMBW * LOAD THEM RT * RETURN TO XBASIC AORG >83C4 * DURING LOADING, GO TO >83C4 DATA LOWCAS * STICK THE ADDR OF THIS ROUTINE THERE END ----------------------------------------------------------------- So that is the end of my article on the use of interrupts in assemble language programs. Hopefully you have some new info now that you can use in future programs. ============================================================================ DTIHM018 40849 28OCT93-2315 Communications Circular Interrupt Input Buffer Operatio From: JHWHITE To: BRADSNYDER Here it is, the complete TI description of the circular interrupt input buffer operation. Home Computer EIA RS232C Peripheral Specification 08MAR 82 7.0 CIRCULAR INTERRUPT INPUT BUFFER OPERATION THIS FEATURE CANNOT BE USED IN A BASIC LANGUAGE PROGRAM BECAUSE OF THE COMMON CPU RAM USAGE, LOCATIONS 0-5. This option is enabled by calling the RS232 peripheral DSR with an operation code of HEX 80, most siginificant bit set plus an OPEN operation code in, the I/O opcode (byte 0) of the PAB. The normal processing for an OPEN command is executed but the receive interrupt is enabled as part of the OPEN. The CPU RAM usage is as follows: LOCATION MEANING 0-1 (2 byte) address of start of buffer area 2 (1 byte) length of buffer (1-255 bytes) 3 (1 byte) callers read offset value 4 (1 byte) RS232 DSR write offset value 5 1 byte NOT DEFINED When the RS232 get an interrupt it attempts to store the the input data byte to VDP memory address (word 0 + byte 4 offset + 1) address. When (byte 3 offset)=(byte 4 offet +1) an overrun error is declared and the data byte at address (word 0 + byte 4 offset) is overwritten with a HEX FE as long as this condition is present. If an input hardware framing, overrun, or parity error occurs and there is not an overrun condition a HEX FF is returned as the character code. When (word 0 + byte 4 offset + 1) > (byte 2) the write offset (byte 4) is set to zero and (word 0 + byte 4 offset) is used as the write address. This functions as a circular interrupt buffer. A user of this feature should read data whenever (byte 3) <> (byte 4). each time a data byte is read (byte 3) should be incremented by one. Inorder to read data increment (byte 3) to the next offset and then use the address (word 0 + byte 3). When (word 0 + byte 3 offset + 1) > (byte 2) the read offset (byte 3) is set to zero and (word 0 + byte 3 offset) is used as the read address. When input is done in this manner the software switch options described in the GENERAL SPECIFICATION SECTION 3.1 have no effect. However the hardware switch options control the input TMS9902. The output section of the port that is OPENed in this manner may still be used so long as the hardware switch options are the same. One OPEN statement can OPEN input for interrupt mode and output with switch options because the interrupt input ignores the software switch options. PAGE 8 ** TI Internal Data ** p.s.: It is typed exactly as it was printed. -*- =========================================================================== DTIHM019 Corcomp RS232 and PIO Internals by Jeff White. 33837 25AUG92-2240 General Information RE: TI FAIR (Re: Msg 33834) From: JHWHITE To: LEIGHTYM Michael: The following is part of a message I sent Email to Dan Eicher and/or Don O'Neil in regards to the Corcomp RS232. Unfortunately, I cannot find the rest of it. Maybe Dan or Don can provide the "rest of the story" if they have filed the message better than I did. "Here are the CorComp PIO port definitions: Pin(s) Function ------ -------- 1 Strobe 2-9 D7-D0 10 Busy 11 Ground 12 10 Ohm PU to +5V 13 Spare Busy 14 Spare Strobe 15 1K PU to +5V 16 GND Here are the CorComp CRU bit definitions and 9901 connections. A10 is inverted to swap P0-P15 to the lower bits: CRU I/O Function 9901 ------- -------- ---- 0 ROM enable P0 1 Spare flag P1 2 Strobe P2 3 Spare strobe P3 4 Flag bit P4 5 RS232/1 CTS- P5 6 RS232/2 CTS- P6 7 LED P7 8-15 D0-D7 P8-15 CRU Input Function 9901 --------- -------- ---- 21 Spare Busy !INT5 22 Busy !INT6 The 9901 interrupt line is not connected to the bus. Bits 0-15 of the CC are really outputs, though their states can be read. P1 and P4 are unconnected, so they act as "flag" bits. P8-P15 can be used as PIO Inputs if the 9901 is programmed properly. !INT1 to !INT4 are unconnected, so they have little functionality. However, the 9901 Clock on an internal !INT3 can be used for timing purposes. !INT7 to !INT15 are shared by P15 to P7, respectively. The card has no buffer chips (244 or 245) on it, which means the 9901 and 9902 chips are not isolated from the backplane bus. Also, applying inputs to the PIO port while the the 9901 is programmed to Output mode on just one of the data or strobe pins can destroy the 9901. It would have been better had bit 1 of the CRU been designated the I/O select bit (as it is on the TI card) such that it could control a bidirectional bus. Software that put the bus into..." I lost a very important part of that message. Note how the data lines (D0-D7) are attached to the 9901 and PIO port -- BACKWARDS! This means that sending out the Corcomp PIO port requires the bits of the data byte to be reversed with a standard cable (and in the standard DSR). Reversing the data bits means program overhead -- an algorithm to reverse them, a lookup table, or some combination of the two. IMHO, it is a colossal waste of a 9901 to use it as it was on the Corcomp RS232 card. 259's and 251's are cheaper, and easier to get, if you want to put the _parallel PIO_ (redundancy for effect) on the _serial_ CRU bus. Sure, if CC had hooked the 9901 up correctly, a simple "LDCR Rx,8" would have worked. Instead, it requires a "LDCR @revbit(Rx),8" or some algorithm before the "LDCR Rx,8" (see source code to Fast Term or Mass Transfer for PaulC's kludge code). On the TI, MYARC, and Ultracomp, you can "MOVB Rx,@PIO" to send out the PIO port. The Axiom interface will use the "LDCR Rx,8" without reversing the data bits -- i.e., Axiom has the data lines hooked INTELLIGENTLY. My recommendation for anyone designing a new RS232 card with PIO port is to simply put the PIO port at byte >5FFE (the top of DSR space). It's quite silly to limit the DSR to only 4K, when 8K EPROM's are not much more expensive. Sure, a new DSR would be needed, but only for the PIO part. The serial ports should still left as is for compatibility reasons. Jeff White (c) Copyright 1992 33855 27AUG92-0119 General Information RE: TI FAIR (Re: Msg 33853) From: JHWHITE To: LEIGHTYM Michael: I never said the bits weren't right on the PIO port. They are attached incorrectly to the 9901. Need an example, huh? Say that you load the value for 'A' into R2 and put it on the CC PIO port: CCPIO EQU >1310 A TEXT 'A' EVEN START LI R12,CCPIO MOVB @A,R2 LDCR R2,8 ... The ASCII value for 'A' is 65 or >41 or b01000001. Now look what that LDCR instruction does. It starts at CRU>1310, puts bit 7 of R2 there, goes to CRU>1312, puts bit 6 there, etc. I.e., the following is what you get: CRU bit Value PIO data line >1310 1 D0 >1312 0 D1 >1314 0 D2 >1316 0 D3 >1318 0 D4 >131A 0 D5 >131C 1 D6 >131E 0 D7 Note that in TMS 9900 lexicon, bit 0 is the MSbit and bit 7 is the 8th MSbit. Thus, what the Corcomp did was put the 8th MSbit of R2 (in the example) at the MSbit position of the PIO port, the 7th MSbit at the 2nd Msbit, or to wit: PIO data line R2 MSbyte MSbit 8th MSbit 2nd MSbit 7th MSbit 3rd MSbit 6th MSbit 4th MSbit 5th MSbit 5th MSbit 4th MSbit 6th MSbit 3rd MSbit 7th MSbit 2nd MSbit 8th MSbit MSbit Now you should see that rather than get 'A' on the port, you get character 130 (b10000010 or >82) on the port. Therefore, to put 'A' on the CC PIO port, you could put the value >82 in R2 and do the LDCR R2,8. In any event, the bits must be reversed in the data byte before being sent out the CC PIO port, or you would rewrite the DSR and swap the data lines on the PIO cable. I've got two MYARC, one Corcomp, one Ultracomp, and used to some TI RS232 cards here. They are all quirky, but by far the Corcomp is the biggest kludge. However, without the '244 on the CC PIO port, it CAN be bidirectional. You must be VERY careful though when hooking an input device to the CC PIO per this version of the card, as it CAN and WILL destroy the 9901 if inputs are allowed while the 9901 data lines are in output mode. It might not do the external device any good either. Now what exactly is wrong with the MYARC PIO? I guess you are referring to the missing CTS lines. Jeff White p.s.: How much does the 9901 cost? How about the 259? I expect on a bad day, you could buy twenty 74LS259's for the price of one 9901 (if you can find it). p.p.s.: If you do copy Corcomp's PIO design, I hope these messages haunt you for the rest of your life. :-) -*- ============================================================================= DTIHM20 Bring your Myarc RS232 into the nineties! By Jeffrey H. White and Dan H. Eicher When the Myarc RS232 card first came out, people were impressed by the fact that this card could be opened at 19,200 bps! TI and Corcomp had only listed open statement up 9,600 bps in their manuals. It was only later ( after we had become much more sophisticated, right? ) that we came to realize that the RS232's manufactured by the big three ( TI, Corcomp and Myarc ) were all capable of very fast speeds. In the cases of Corcomp and TI cards, 19.2 ( as it is commonly called ) was not coded into the DSR bit rate tables, but they are actually capable of these speeds and more, if you are working in assembly. What follows below is two modifications that can be made to the Myarc RS232 card. The first is a simple fix that will make the second serial port function. The other is an upgrade/enhancement to the abilities of your card! Some people ( myself included ) have had difficulties using the second RS232 port on Myarc cards. This is because of a design screw-up. The orginal board layout did not properly implement the RS232 port. The DTR line from pins 18 and 19 was hooked up to an output of the quad line receiver (1489), and the corresponding input was then connected to the !CTS (pin 6) and !DSR (pin 7) inputs of the 2nd UART (9902A). It only takes three jumpers to fix this, but some times these jumpers were installed wrong or not at all by Myarc when shipping RS232 cards. Here is what you need to do to ensure your card is modified to function properly with its second port: The trace from pin 4 of the 1489 must be cut so there is no continuity with pins 6 and 7 of the closer 9902A. Still on the front of the card is a trace from pin 6 of the 1489 to a solder pad between pins 4 and 5 of the quad line driver (1488) that must be cut. On the back of the card, the trace from pin 6 of the 1489 to the leg of a 2.2k resistor must be cut. On the back, run a jumper from the solder pad between pins 4 and 5 of the 1488 ( trace from pin 19 of the D-sub ) to pin 4 of the 1489, then from that pin 4 to the leg of the 2.2k resistor. Jumper from pin 6 of the 1489 to either pin 6 or 7 of the closer 9902A. If this is done correctly, your second RS232 port should work, given no bad solder joints or chips. The quickest and easiest way to check this modification out is to use a TI built Y-splitter cable for the RS232 and hook a modem with status lights up to the second port. If everything seems to work, you are set. Alternatively, if you have a Y-splitter cable and a breakout box, you can now use the breakout box to test functionality of the second port. On to the enhancement: As high speed modems have become more commonplace, a few transitions in the typical use of RS232 have occurred. The first being in the area of speed. When the TI RS232 card was originally designed, one of its primary purposes was to interface to a printer -- in fact, TI's impact printer ( an Epson with the TI logo ) was designed for serial usage. The maximum bit rate for the typical printer of that time was around 120 CPS ( Characters Per Second ), with each character requiring around 9 bits, so it was no real challenge for the RS232 port to keep up with the printer. Very quickly, with the rise of the TIBBS BBS by Ralph Fowler, hooking up a modem became the thing to do..... We have all seen the gradual increase in modem speeds occur. First 300, then 1200, followed shortly by 2400. But, only within the past year have 9600 and 14.4 modems become affordable to us common users. While 300/1200/2400 bps modems present computers and serial ports with little challenge, the same can not be said for speeds over 9600 ( actually a 9600 bps modem runs even faster, if you consider modems implementing MNP5 and 42 bis utilize 'on the fly' data compression ). The first change that must occur to accomodate faster communication speeds is your communication software. There are two primary methods of handling flow control. Flow control refers to the agreed upon way of deciding if the computer or the device it is talking to ( a modem perhaps ) is ready to send or receive. At low transmission speeds ( under 9600 baud ) the most common form of flow control is called XON/XOFF. This can be accomplished using only 2 wires ( Transmit and Receive ). This works based upon the practice that both devices have agreed upon characters they will both utilize for "OK to send" (XON) and "Whoah, hold on a sec!" (XOFF). This method does not work very well at high speeds. The problem is, in between the time it takes for one system to say, "Whoah, hold on a sec!" and the other system actually "Whoahs," an awful lot of data can pass under the bridge. So, what do you do? You use some more of the pre-defined control wires in the RS232C definition. The wires most commonly used for this function are DTR and RTS. However, the current RS232 cards are wired like a modem, so the wires that we will use are properly called DSR and CTS. You need not understand this peculiarity of the RS232 cards. In order to fully explain the modification we are about to make to your card, a little hardware detail will be presented. In the TI RS232, TI used certain Communication Register Bits to control the functionality of their card. Here are the TI definitions as compared to current and added definitions on the Myarc: Bit # Function Myarc 0 DSR ROM page Bit, 1=active Same 1 PIO Port Mode Control, 1=Input STROBE 2 PIO Output "STROBE" bit Mode Control 3 Spare PIO output strobe LED, 0=On 4 Flag Bit, 1=Set DSR (*) 5 CTS - control, Primary RS232 port, 0=Active CTS 1 (+) 6 CTS - control, Secondary RS232 port CTS 2 (+) 7 LED Control, 1=ON spare (*) - This pin's usage is NEW to all three cards, and it can be used to hang up a modem by toggling the modem DTR line. Some terminal emulators and some BBS software packages connect the secondary CTS line to the modem DTR line to implement this function. (+) - These are the flow control lines new to the Myarc card. Those terminal emulators and BBS software packages that connect the secondary CTS line to the modem DTR line, do not work with Myarc cards, because the CTS line is in-operative as supplied by Myarc. We will fix that. ENHANCEMENT ( Working Directions! ) The first thing you will need to do is run down to your local Radio Shack and pick up part number 276-2520, its a MC1488. ( FYI - its mate, the MC1489, is also available as part number 276-2521. They are both listed as costing $1.29 a piece in the '94 catalog.) While you are there you may want to pickup some wire-wrap wire (278-501,502 or 503 ) and a wire-wrap wrapper/stripper (276-1570) -- the stripper part is hidden in the handle! In fact, you can pull the wrapper portion out of the handle and stick it on cordless screw driver and make an auto-wrap tool! Ok, if you have a soldering iron and solder we are good to go..... Step 1. Take the cover off. Step 2. Orient the board so that you are looking down at the chips and the edge connector is facing you. Now remove the 3 resistors in the top right-hand corner. You now have six holes where the resistors use to be, fill the three on the left-hand side with solder. Make sure the holes on the right-hand side are clear, because you will be sliding jumper wires through them. It will look something like this.... 1 * * 4 2 * * 5 3 * * 6 ___ ___ 1 =| U |= 14 2 =| |= 13 3 =| 1 |= 12 4 =| 4 |= 11 5 =| 8 |= 10 6 =| 8 |= 09 7 =|_____|= 08 Step 3. Take out your new 1488 and piggy-back it to the existing 1488 by soldering pins 1, 7 and 14 together ( if this chip is socketed, please remove it from the socket before piggy backing it ). Next bend up the unsoldered pins. Step 4. You will need three short and three long jumper wires. Solder a short jumper wire from solder hole 4 to pin 11 of the piggy-backed 1488. Solder another short jumper wire from solder hole 5 to pin 6 of the piggy-backed 1488. Solder the final short jumper wire from solder hole 6 to pin 8 of the piggy-backed 1488. Now for the long jumpers. Solder pins 4 & 5 of the piggy backed 1488 together. Run a jumper wire from that connection through solder hole 2. On the back side connect this to pin 11 of the 74LS259 ( which is the farthest chip away from the 1488 on the top row). Note: Since you are now working on the backside of the board, pin numbering is reversed, so the 259 we are talking about is numbered like this: ___ ___ 16 =| U |= 1 15 =| |= 2 14 =| 7 |= 3 13 =| 4 |= 4 12 =| 2 |= 5 11 =| 5 |= 6 10 =| 9 |= 7 09 =|_____|= 8 Solder pins 9 & 10 of the piggy-backed 1488 together. Run a jumper wire from that connection through solder hole 3, on the back side connect this to 09 of the 74259. Solder pins 12 & 13 of the piggy-backed 1488 together. Run a jumper wire from that connection through solder hole 1 ( now the only one remaining ). On the backside connect this to pin 10 of the 74259. OK, that's it for the hardware mods. Double-check everything. Tape down the three long jumper wires on the back and put the case on. You have now added three more control lines to the RS232 port that you can use to implement hardware flow control in your software. Here are the assembler instructions to manipulate these three lines: LI R12,>1300 CRU base of RS232 card 1 SBZ 4 activate DSR SBZ 5 activate primary CTS SBZ 6 activate secondary CTS SBO 4 de-activate DSR SBO 5 de-activate primary CTS SBO 6 de-activate secondary CTS CRU bit 7 is left as a spare. There is also a spare line driver on the MC1488. We could attach pin 12 of the 74LS259 to pin 2 of the MC1488, then run a wire from pin 3 of the 1488 to an otherwise unused pin on the 25-pin RS232 connector. Another option would be to use CRU bit 7 for another control signal out the parallel port (without using the 1488). Right now we are happy to have "fixed" the MYARC RS232. About the only thing we have not discussed in this article is how to change the Myarc card from RS232/1&2 to RS232/3&4. This will be explained later in a user note. Many people have asked us where can they buy hard to come by 99XX chips ( such as the 9902A's used in the RS232). There are two routes to go. One not so sure, but very cheap, the other guaranteed to have what you need, but a little on the pricey side. The cheap route: look in your local phone book for computer scrap or salvage people. They usually have tons of 99XX chips that they will be glad to part with at a fair price. The more expensive route is to call Newark Electronics at 1.312.784.5100. These people should be able to tell you the number for your local Newark office ( or just look in the phone book under electronics ). They have 9901's, 9902's, and a few others. L.D.O.M. 03.26.94 ============================================================================ DTIHM021 39139 8JUN93-2122 General Information RE: SKEW (Re: Msg 39135) From: JHWHITE To: JERRYC Jerry, I still think this needs to be clarified a bit further, especially your definition of rotational delay. I can live with the definition of skew, since it is rather simple to visualize and is what HyperCopy reports. What bothers me about the definition of rotational delay is that it assumes the disk will rotate past the index hole after stepping from any track to the next. Assume the following is the logical sector pattern for two tracks of a disk: 0 1 2 3 4 5 6 7 8 <-- physical sectors o 8 4 0 5 1 6 2 7 3 o 5 1 6 2 7 3 8 4 0 The interlace is 2, and the skew is 6. The rotational delay stepping from the first track after reading its last LOGICAL sector to the next track and the availability of its logical zero sector is the time it takes to pass over physical sectors 1 through 7. This is 7 sectors. A single density TI disk can have approximately 25,000 bits of information, or 3,125 bytes per track. Seven 256-byte sectors is 1,792 bytes plus the gap bytes. The rotational delay takes over 100ms during the step. Therefore, if 35ms is the optimum rotational delay for this disk, there should be over 60ms for the disk controller to re-synchronize to the second track without passing the last physical sector or the gap information preceding and following the index pulse. Jeff -*- ============================================================================= DTIHM022 46809 7JUN95-2243 9640 GENEVE RE: Three and a half inch drives (Re: Msg 46798) From: JHWHITE To: JCARVER John, maybe I can explain it simply. The Geneve will boot from an 80-track disk in an 80-track drive with any controller. This includes the TI floppy controller, but you are limited to single density. Once MDOS is loaded, it defaults to how the controller would work on the 99/4A. In most cases, this would make MDOS treat the drives as 40-track. Unfortunately, in sector 0 of the disk, it is marked as being 80-track. This is not so bad, I suppose, if the OS -- that is, MDOS -- can be set to treat the drive as 80-track. It just so happens that if MDOS ignores the tracks-per-side value stored on the disk except when the drive is considered 80-track, the first 40 tracks on side 0 of the disk can be treated as the entire side of the "imagined" 40-track disk. Sector 1 of the disk holds the file descriptor index records, and these are actual sector number values. Therefore, read operations of files that completely fit within the first 40 tracks of side 0 are accessible (I think) just as if they were on a 40-track disk. So AUTOEXEC and SETDSK can be at the beginning of the disk to force MDOS to 80-track drive operation. If SETDSK is not used, the 80-track disk would be corrupted by writing to it. This is because the bitmap in sector 0 -- not used during most read operations -- for a 720K disk marks allocation units consisting of 2 sectors each. Each time an 80-track disk bitmap were updated as if it were 40-track, additional sectors would be marked as used. If we compare the logical sector layout of a 40-track disk to an 80-track disk, we can see the logical overlap: 40-track 80-track Side 0 0-719 0-719 ----- 720-1439 Side 1 ----- 1440-2159 720-1439 2160-2879 Getting less murky now. Whether MDOS thinks the drive is 80-track or not, it will translate sectors 0-719 as an access to side 0 of the disk in the first 40 tracks. Sectors 720-1439 would not be found, because MDOS would look on the wrong side of the disk for them -- in the area reserved for sectors 2160-2879. This is because sectors count up on side 0 as the read/write heads move toward the hub, and ALSO count up on side 1 as the read/write heads move away from the hub. Looking at the physical overlap of the sectors, we have the following: 40-track 80-track Side 0 0-359 0-719 360-719 720-1439 Side 1 720-1079 1440-2159 1080-1440 2160-2879 The drive logic always treats the outer (largest concentric) track as track 0. On a 40-track disk, side 1, moving the head to track 39 (the 40th track) finds sector 720. On an 80-track disk, side 1, moving the head to track 39 finds sector 2160. If this has not made your head spin faster than your floppies (300rpm in most cases, 360rpm for 1.2 Meg 5.25" and single density 77 track 8"), what happens when you format a disk in an 80-track drive when your software treats it as 40-trac? It makes it logically look like a 40-track disk (whilst in an 80-track drive running 40-track software). In this case, the physical overlap is: 40-track 80-track Side 0 0-359 0-719 360-719 ----- Side 1 720-1079 ----- 1080-1440 720-1440 Now I am beginning to think of onion slices and at least 4 food colorings to bring this discussion to yet another level.... Thankfully, I was taught not to play with my food. And disk formats are certainly nothing to cry over -- unless of course it is an accidental format of the disk holding valuable data. Jeff White -*- ========================================================================== DTIHM023 Disk Controllers -- an Addendum March, 1987 By Jerry Coffey I mentioned a "turbo" modification to lock out the "read after write" (write verify) routine usually performed by the controller. Here are the details: Find the 74LS251 chip at the top center of the controller board, above the DIP switches and beside the large FDC chip (marked WD1770). Solder a wire from the number 2 pin of the 74LS251 through a switch to ground (e.g. the wide trace of the DIP switches or any trace connected to that wide trace). It looks about like this from the bottom (non- component side) of the board. | ______________________ _______ | / Switch to ground | .|...... top | -------- ---- ^ of | | | |DIP | | Myarc | > | |swch| Location of the contrlr | |74LS251 | | | switch is up to you board-->| -------- ---- | | ----------------- | | | | | | | | | | > WD 1770 | | | | | | (or 1772) | | | | | ----------------- | As always you proceed at your own risk. (One person has told me this did not work om his 40 track system, but I haven't verified that.) You can tell it is working if your controller writes as fast as it reads (normally the write takes twice as long). Since I wrote the article on disk controllers, I have discovered some surprising facts about my own system. All of the Myarc timings in the article were done on an 80 track system with the fast WD1772 controller chip (stepping at 2ms). With some help from Paul Charlton and Richard Roseen, I recently customized Paul's Eprom to step at 3ms using the WD1772. (Richard's drives were making errors at the faster speed.) I used a Mechatronics Eprom programmer to download the Eprom code to disk, changed the FDC commands with a sector editor, and wrote the altered code back to a fresh Eprom. The process is simple (and cheap) once you decide what code you need in the Eprom. The slower step speed made it possible to notice some slight differences in the performance of the WD1772. The first thing I noticed was that interlace 4 on 18 sector tracks was no longer smooth -- it was missing the first sector after a track seek and forcing an extra revolution of the disk. This was the first clear indication of how close this format is to the "ragged edge". The reaction to the small change in step speed implies that this interlace comes within 5% of the minimum time required to step and settle the head. Thus the likelihood of read/write errors is relatively high with this interlace. It will occasionally detect the sector ID and begin to read or write before the head has completely settled. This interlace should definitely be avoided -- 18/3 is both faster and more reliable. The Eprom modification itself was an interesting experience. I patched the new FDC commands into some unused text bytes and patched addresses into the code to point to the new locations. The Mechatronics Eprom Programmer is an excellent piece of equipment. It will burn (program) a 2764 (8k) in about 90 seconds using the fast algorithm. I have talked to Jim Horn and Jeff Guide about offering an Eprom service to the customers of Disk Only Software. There are many possibilities this technique opens up. There is the 80 track modification for the TI controller worked out by Andy Cooper. And many Myarc owners are still using old Eproms that have never been upgraded (though this situation has improved since Lou Phillips increased his production capacity). The fix we developed for Richard's controller can provide the optimum step speed (3ms or 5ms) for different disk drives using the WD1772 FDC chip. And any enterprising programmer can get his tailor-made code installed in nonvolatile memory. Jerry Coffey [74716,3525] ============================================================================ DTIHM24 A Hard Drive Odessey (Oddity) By Dan H. Eicher & Jeffrey H. White Recently I put a one gigabyte SCSI drive on my pc. (A personal note: if you are going to use SCSI on a PC, buy an Adaptec brand controller.) This left me with two Seagate ST277R hard drives that had performed five years of great service. About this time, Jeff and I were assembling a system to work on the GenMod Geneve / WHT SCSI compatibility problem. Of course I needed two external cases to hold these drives. The best place I found for getting external cases with power supplies is Mendelson's Electronics: 1-800-344-4465. Their supply is hit and miss, but they usually have something usable at a very reasonable price. I got my cases in and built the cables. While you can still buy RLL controller cables - which are usable with the Myarc HFDC - usually the length is wrong so you will need to build your own. You can buy the parts you need to build the cables from JDR Micro Devices: IDE34 - 1 to hook to the HFDC plus an additional connector for each HD. IDE20 -\ These are the data cable. 1 each for every hard drive. IDS20 -/ IDS16 - This is the TI side of a printer cable. IDCEN36 - This is the Printer side of a printer cable. To crimp these cables you will need a vice ( if you go this route, you need to be very careful ) or buy a cable crimper. JDR's part number is HT-214 and is well worth the money. We got the hardware assembled and now it was time to reformat the hard drives to work on the TI. We dug out our specifications on the drive ( I still have my orginal owners manual ) and put the values into MDMV. We had to guess at the interlace value for the HFDC/Seagate 277R drives and GenMod geneve combination. After the formatting was finished, the drives could be read, but not written to. We tried over and over with different MDMV settings. None of them seemed to work. In a moment of desperation I tried using CFORM; I had the same luck as MDMV. In order to save myself some time, I decided to try only formatting the first 10 cylinders in my quest for a working (not optimal, but working) interleave. Well after trying this little stunt, CFORM came back and told us that track 0 or media on this device was BAD! Yegads! After this error message we could not coax another complete format out of either MDMV or CFORM. Our last resort, and it was a last resort, was to put together a PC system with an RLL controller. Fortunately, Jeff owns an original Seagate brand RLL controller. Immediately, the Seagate controller recognized the drive and type. It made quick work of the formatting of these drives. We moved the drives back over to the GenMod Geneve system and this time the reformatting went without a hitch. I could read and write data with no problems. In fact, the drives seemed to work much quicker than similar drives we have in house. Later we went up to Chicago and asked Mike Maksimik what he thought my have went wrong. He told us that probably the gap value between sectors was too small for the drive - that is, a bug in CForm. He knew how to fix the problem, but apparently there is a disagreement between Mike and Don Walden regarding royalty payments, so no fix will be forthcoming from Mike. We asked Mike why CForm could not just go in and redo the gap values, like the Seagate controller did. Mike says that this a bug in the 9234 controller chip used in the HFDC. In simplistic terms, the chip must read this value before changing it. If the value is wrong an error is returned. The chip should then disregard the error, and reformat with the correct value. The 9234 has a fatal bug, that if an error occurs during this process the chip locks up. There unfortunately is no way to work around this problem in software. This is the reason why occasionally a hard drive will become so messed up on a TI, the only recourse is to take it to a PC and do a low level format with an RLL or MFM controller card. A few notes: We have found that RLL drives seems to work fine with the Myarc HFDC. You should always attempt to use the buffered head step (0) in the MDMV menu. You should avoid using CForm, and only use MDMV on the Geneve to format drives. Of course to load MDMV and use the format routine on a Geneve you must page in the ROM. Using RomPage means that the Geneve's Master DSR is paged out, so the only devices you have access to are drives connected to the HFDC and/or those connected to a Myarc floppy controller. It is much easier just to hook up a TI and format the hard drives and then use them on the Geneve. If you want to load MDMV on a Geneve to format with and you need the Rom Paged in the easiest way is to go into TI BASIC, issue a CALL INIT, CALL LOAD(-32766,186), NEW, and then do a CALL MDM. Also when purchasing connectors to build your cables, always buy high quality, gold-plated, double-leafed connectors. While moving MDOS source code around and testing the GenMod Geneve and WHT SCSI card we have found the Syquest EZ135 to be very reliable. It works as fast as all but the fastest SCSI hard drives on the Geneve, offers removable media of 135 Megs and can be set at any SCSI ID. The Syquest drive is the perfect companion for a WHT SCSI card. We have also played a bit with the Iomega SCSI Zip drive. It is a MUCH less reliable unit, it is locked into SCSI ID's 5 and 6 which are incompatable with MDOS. MDOS wants to see all hard drives at ID's 0, 1 and 2. Global Computer Products has a sale on SyQuest EZ135 for 179 dollars, part number GDC92225E, the phone number is 1-800-845-6225. L.D.O.M. 05.01.96 ============================================================================ DTIHM25 The 9224: A failed experiment or an educational experience? by Dan H. Eicher, eicher@delphi.com and Jeffrey H. White, jhwhite@delphi.com About three years ago Beery Miller was working full bore on trying to implement the level 2 routines for the Myarc Hard Floppy Disk Controller (HFDC) in MDOS. He was having some problems so he called Standard Microsystems, the people that make the disk controller chip in the Myarc HFDC. At that time the support engineer he was talking to told him that the 9234 was a buggy chip - somewhat experimental. He recommended a complete redesign of the controller board to use a then newer chip that would support the then current RLL hard drives. This not being possible, he recommended the possible retro-fitting of the Standard Microsystems 9224 disk controller chip which appeared to be pin for pin and register level compatible with the currently in-use 9234. Beery said the only difference mentioned to him by the support engineer was that the 9224 and the 9234 computed their ECC value differently. Meaning that a hard drive used on one chip could not be used on the other with out reformatting. Beery got in a couple of the 9224 chips to test. He tried one of the chips in his HFDC. At that time he didn't have a spare hard drive and no easy way to back up his system. After placing a 9224 in his HFDC he found that he could no longer read his hard drive. His experimentation with the 9224 stopped there. About two years latter, Jeff and I got a couple of 9224 from Standard Mircosystems. It says in their component catalog (1988 version) that these chips were designed to be used in Vaxes and Microvaxes, sometimes called Vaxen. Another year or so went by until we got a spare HFDC and hard drives to try some experimentation. Neither of us were willing to risk doing experiments on our only HFDC, they being very temperamental and all. Jerry Coffey was kind enough to loan us an HFDC to do some testing with. Now, with all that preamble, we finally got around to doing the experiments. I set the HFDC at CRU >1000 thinking that that would be a good CRU setting, allowing us to use DSK1 emulation even if, later on, we decided to add floppy-only controller. We hooked everything up and the floppy drives were chattering and doing all sorts of weird things... This, the first of a long series of problems, was caused by a CRU conflict between the HFDC and the Myarc 512K card we were using. The Myarc 512K card responds at CRU >1000 (and >1900). LESSON: Make sure your HFDC is not set at a CRU-base that conflicts with another expansion card in your system. To solve this problem, I needed to change the HFDC's CRU address to >1100 so that there would be no conflict with the Myarc 512K card. To verify that the card was set to the correct CRU I used the Minimem module. Here is the procedure I used to verify that the HFDC was showing up at the CRU >1100 space. I selected Minimem, then I selected Easy Bug. I typed C1100 <space> then 1, hit <return>, then the period key. This activated the card. Now its DSR memory should show up starting at >4000. So I typed M4000 and hit <return>. Easy Bug then responded back with the hex values held at the address starting at >4000. These values should be: >4000 AA >4001 OB The >AA means that this is a valid DSR. The >0B is the revision of the DSR. The current working revision is 11. A version 12 DSR was distributed, but it was found to be more buggy then version 11! With the HFDC's CRU set up correctly, it was time to hook the hard drives back up and see what would happen. Still the same problem...floppy drive chatter... argh... OK. Next step was to make another quick visual inspection of the card. Quickly I noticed a problem. The part of the card that sticks out past the end of the P-box did not have any electrical tape. Myarc made an engineering blunder. They had ran control lines from the AM26LS32x chip to the hard drives on a portion of the card that is scraped by the metal clips of the P-box. LESSON: Make sure the neck of the HFDC is protected with tape. This was easy to fix with a little electrical tape around the neck, and we were ready to go again. We tried again. Same Result. Jeff noticed that the card had an AM26LS32PC. He has had some problems with this chip in the past. This version of the chip is a marginal component. The recommended replacement is a AM26LS32AC. We didn't have one of those so we tried omething else. Note: the AM in the part number signifies an AMD part number. LESSON: If your system is acting quirky - replace the AM26LS32PC with an AM26LS32AC. We disconnected the hard drives from the HFDC. The system powered up but wouldn't access floppy drives. Oops! I had forgotten about the 45 second delay, while the HFDC repeadedly waits for a hard drive to activate its ready line. After waiting for the controller to time out, I could access the floppy drives fine. To defeat this power-up timer you must take pin 1 of the inner most LS251 (U21) to ground, pin 8 works well for this, and you may want to put this on a toggle switch. - This information courtesy of Tim A. Tesch. LESSON: Either jumper your card to bypass the hard drive power-up wait timer or wait 45 seconds. All we had to do now was hook up the hard drives and test things out. More floppy drive chattering and then no access to the floppy or the hard drives. At this point, I was nagging Jeff to come up with more ideas. He decided to offer his HFDC for sacrifice. No, he did not torch it -- it does a good enough job toasting itself while in the P-box. Jeff swapped his with the HFDC from our test system -- the HFDC Jerry had sent us. The alternative was to take the hard drives from his Geneve and try them with Jerry's HFDC. Too risky. The data on the hard drives is worth more than the controller. Same symptoms. Had Jeff's HFDC been fried? Jeff then decided to bring his hard drive to the test system with his HFDC. With Jeff's HFDC and hard drive, the system worked fine. Jeff then tried his hard drive with the HFDC Jerry had sent. This combination worked as well. Using Jeff's known working set of cables, we were able to format one of the hard drives we had for testing. We decided to try something new. We swapped our test cables one at a time with Jeff's known working cables until we determined the original problem was with the control cable - the cable with 34 pins. ( The other cable is called the data cable. ) I checked out this cable with a voltmeter and everything appeared fine. Theorizing that it might be a problem with the length - it was about 6 feet long - I cut the cable in half and applied another connector (Radio Shack part number 276-1564). We tried it with this now shortened cable with a new connector and we still had the same problems! We then sat down and checked each pin on the cable for continuity - the size had been reduced to half the previous length and the pins rechecked. But STILL no difference. Then, Jeff got a bright idea. He reversed the cable, not just rotating the cable 180 degrees on one end or the other, but a 180 degree turn on both end! What we were using as pin 1, now become pin 34 and what was pin 34 became pin 1. This time the system fired up without any drive chattering. How could reversing the cable make a difference on a cable with straight through connections? Well on the connector - all odd number pins are used for ground and all even numbered pins are used for controller signals. Our theory is that one of the strands in the ribbon cable had a crack in it, causing high impedence, but only when it was twisted a certain way. This strand when connected the orginal way was on an EVEN-numbered pin (i.e., a control signal), when the cable was reversed it placed the bad strand on a ground line. Having one bad ground out of 17 ommon grounds didn't cause a problem. LESSON: Always suspect cables. Always have a spare set of known good working cables on hand. With the system working we formatted both hard and floppy drives without problems. We pulled the HFDC and put in the 9224. The first thing we noticed was terrible drive chattering. We thought this might be because of the slower step rates of the 9224 as compared to those of the 9234. We tried various dip switch settings on the HFDC, but were not able to get the floppies working. We changed the HFDC's CRU setting to 1200, inserted a Corcomp disk controller and went on. The next test was to try to access a hard drive previously formatted with the 9234. Neither hard drive could be read. We (and Beery) expected that this would happen since the two controller chips compute their ECC codes differently. We had also hoped that Beery's theory was correct that if you reformatted a hard drive with the 9224 that it would be usable. Well, despite many attempts (including upgrading the static memory on the HFDC from its factory default of 8K (6264) to the full 32K (62256)) we were never able to format a hard drive with the 9224 controller chip. LESSON: Always have the full 32K of memory on your HFDC. After exhausting all possible hardware options, it would appear that without modification to the existing Device Service Routine software, that the 9224 Hard Floppy Disk Controller Chip is not usable on the HFDC. Other things that you can do to help make this temperamental piece of equipment more robust is to make sure the 26LS32 is an AM26LS32AC. You should also verify that the 9216 chip is a 9216B - this chip is the data separator. The 9216B is specified for faster data throughput. The 9216 is overclocked at 8 MHz, but it may work fine for double density disks. In order to use high density floppies or tape backup devices, you must use the 9216B. I have a hand full available for five dollars each ( includes shipping ). You should also add heat sinks to the two 7805 voltage regulators. A good cleaning with an eraser tip should also be done, if you notice any dirt on either the P-Box edge connector or hard drive control cable connector - the silver looking connector. This silver connector is coated with a tin-lead compond and does not provide a real good connection - like gold platting would. L.D.O.M. 12.19.95 ============================================================================= DTIHM26 Fixing Blown Bit Maps on the HFDC by Edward Hallett From: The Catus Patch BBS 11/10/90 By: TOM WILLS 1 (TUCSON AZ) To: ALL Sb: HD DIRECTORY FIX I was asked if I knew of a way to copy all the files off an HD on the TI which has bad directories. The directories are not totally blown, just a few entries. And, of course, MDM will not read those directories. Any ideas on this one? Also, not all directories are bad, just some. The MDM backup will not work because of this, nor can he copy the files from the subdirectories which have bad pointers in them. In other words, HELP! By: EDWARD HALLETT 6 (TUCSON AZ) To: TOM WILLS 1 (TUCSON AZ) Sb: HD DIRECTORY FIX Tom, I have had to deal with blown diries and or blown file headers on both Ida's and my harddisks on several different occasions. The vast majority of the files can be salvaged in most cases. The range of difficulty will depend upon th number of blown sectors, their location and the size of the hard disk. Files for which a backup copy exists on floppy do not need to be recovered but only need to have their blown pointers removed so that the other files can be copied off the hard disk. Files that do not have a backup on floppy need to have their headers, pointers, directories etc. repaired so that they can be salvaged by copying them off the hard disk. I use a program called Hard Master by Asgard Software I think, when I need to fix a hard disk. The Hard Master program is similar to the SectorOne program but I like Hard Master better. It is a hard and floppy sector editor with a Tree function, Map function, and much more. Its docs also explain alot about the hard disk sector mapping etc. As far as procedure to fix the hard disk I would suggest the following as a general procedure. 1. Run the hard disk test with MDM5. this will mark any bad sectors. Note the number of bad sectors found and their approximate location on the hard disk. Are they all at the begining of the disk, some in the middle etc.? 2. If any bad sectors were identified during the test try to identify the exact sector numbers by using Hard Master to step thru the sectors in the suspected area with its sector read function. 3. Using Hard Masters Tree function print out a tree listing of the directories only. If a bad sector is a directory sector you will have to remove the pointer to that directory to get to the rest of the directories. 4. Using the Tree Function after removing any pointers that were causing trouble print out a tree listing of both directories and files. These tree listings tell you what sors the headers are in and what sectors the file act- ually occupies. You may hit some bad pointers during the file tree listing and they will have to be removed before you can get the listing to complete as in the directory tree listing. 5. At this point you should have a detailed tree listing of both directories and files and a list of bad sector numbers. You would also have recorded any information about the pointers you may have removed. With the bad pointers removed and the bad sectors marked you should now be able to copy the remaining files from the hard disk to floppies. I would recommend doing this file by file rather than with the back up routine. Of course you only need to copy the files that you don't already have backup copies. 6. At this point you are ready to rebuild the pointers for the directories and or files that you had to remove to get the other files off the hard disk. If the directory or file header was located in what is now a bad sector just pick an unused sector at the top of the hard disk and write your new header block there. then put the pointer in any good directory or the root to point to the new header. Once this is done you can simply copy the file otire directory off to floppy. If the directory or file header was just scrambled and not in a now bad sector you can rebuild it where it is. 7. Using this procedure you can recover all the files from the hard disk with the exception of a file that now has a bad sector in the middle of the file. In that case you must change the header to skip that sector. Sort of like fracturing your own file. Then you will have recovered the file minus one sector. Reconstructing that sector may or may not be possible depending on the file, (data, text, program etc.). Now that is the basic procedure and it has worked very well for me. The specifics of removing pointers, rebuilding headers etc. is similar to those on floppies. The information needed to do this is available in the HFDC manual and in the Hard Master manual. The specifics also depend upon the actual problems with the specific hard disk. The persons' experience with working with floppy headers, their ability to work with hexadecimal math and their ability to multiply alot of the hexidecimal pointers by an offset constant to get the actual sector number (this can be confusing). If you try to read a bad sector and get a device error you will probably have to rerun the Hard Master program in order to continue reading sectors. (Does not recover well from device error ie bad sector). I had to tell if to switch from HD#1 to HD#2 and then back to HD#1 to recover from error and continue. You may also experience similar problems with other sector programs and MDM5. So it is iportant to identify those bad sectors and make sure your software is functioning correctly after a device error before attempting to write to the hard disk (sector write or file copy) or yould just make things worse! When in doubt reboot or rerun before writing. You didn't say if this hard disk was on a 4A or a 9640 but the procedure is the same. Give me a call land line if you need more info. I would be glad to help. I'd be glad to tell you about some of the specific problems that I have had to repair on hard disks. Once the hard disk is restored to normal ie fixed the bad directory and files, copied everything off, reformatted, copy everything back on, you can make it easier for future recoveries by copying sectors 0 thru 1 to sectors 20 thru 39 (HEX of course). This gives you a copy of all the directory information and can be used to restore the directories to the state they were in at the time this info was copied. Also helpful is to print out a tree listing of all directories and files showing their sector locations etc. And of course doing regular backups of the hard disk would be very useful! I think that almost any hard disk could be recovered with theurse) and start rebuilding directory headers! Well give me a call if I can be of any additional help. Or if you need more info about Hard disks. If I can make it to the SIG I'll try to remember to bring Hard Master also for a little demo and we can print out a Tree listing for your hard disk just in case you ever need it. ============================================================================= DTIHM027 CPUID & VDPID by Jeff White 40176 2SEP93-2117 Communications RE: PC99 and TELCO (Re: Msg 40175) From: JHWHITE To: MARKVC To clarify that a bit, V14 is used to change the 16K page of VRAM used by the V9938/V9958. If data is written to page 0, which is all that exists on the stock 99/4A, and the page is changed (only possible with V9938/V9958), the data will not be there. However, since the page does not change on the 9918A, the data will be found. The 9918A may mask V14 to V6, and V6 sets the sprite generator table base address. Because sprites are inactive in the text modes which Telco uses, changes to V6 do not affect the video display. I have a more innocuous routine, called VDPID, that works on a different principle. The only side-effect is that the text mode and background colors are changed, but the routine does change them to what the programmer gives the routine. Jeff -*- --------------------------------------------------------------------------- * * * * CPU identification routine by Jeffrey H. White * (c) Copyright 1991 * * Usage: BLWP @CPUID * * Returned values in R1: if 9900, = 1 * if 9995, = 2 * if 99000, = 3 (Privileged Mode) * = 4 (User Mode) * CPUID DATA $-16 R8 location DATA CPUPC R9 location CPUPC BES 12 skip over R10-R15 LIMI 0 try to turn off interrupts LWPI CPUID-16-6 to preserve R13-R15, new Rx = old R(x-3) STST R15 store status SLA R15,12 are interrupts off JNE C99000 no, then definitely in 99000 User Mode STWP R13 store current WP LI R14,CONTIN trick with PC required by LST-less 9900 LI R15,>0020 after RTWP, ST10 will be 1 only on 9995/99000 RTWP load ST, keep current WP, and execute next CONTIN LI R14,>0001 load value to return if 9900 STST R15 ST10 was not affected by previous instruction SLA R15,7 check ST7 for Privileged (Supervisor) Mode JLT C99000 ST7=1 always on 99000 in User Mode JEQ C9900 ST10=0 always on 9900 MOV @>FFFA,R15 9995 on-chip decrementer location AI R15,>8000 most distant value from decrementer MOVB R15,@>FFFB byte writes to 9995 decrementer mess up both AI R15,>8000 restore register to previous decrementer value CB R15,@>FFFA decrementing is not fast enough for bytes to equal JNE C9995 on 99000, memory or not, >FFFA will not change INC R14 only executes if 99000 is found C9995 INC R14 only incremented once if 9995 MOV R15,@>FFFA restore the value C9900 LWPI CPUID-16 restore entry WP MOV R11,@>0002(R13) put at caller R1 RTWP finished C99000 LI R14,>0004 value returned if 99000 User Mode JMP C9900 go exit ------------------------------------------------------------------------------ * * VDP identification routine by Jeffrey H. White * (c) Copyright 1991 * * Usage: BLWP @VDPID * * Returned values in R1: if 9918A, = 1 * if V9938, = 2 * if V9958, = 3 * VDPWS BSS 32 VDPID DATA VDPWS DATA VDPPC VDPPC LI R10,1 LI R0,>0F04 BLWP @VWTR VDPST MOVB @VDPSTA,R12 JGT VDPST JEQ V9918A MOVB @VDPSTA,R12 JLT V99X8 JMP V9918A V99X8 LI R0,>0F01 BLWP @VWTR MOVB @VDPSTA,R12 SLA R12,5 JLT V9958 JMP V9938 V9958 INC R10 V9938 INC R10 V9918A LI R0,>0F00 BLWP @VWTR LI R0,>07F4 BLWP @VWTR MOV R10,@>0002(R13) RTWP * * =========================================================================== DTIHM028 40312 10SEP93-1251 Graphics bitmap mode explained again From: JHWHITE To: ALL In article <1993Sep8.013025.4524@ultb.isc.rit.edu>, digger@ritcsh.csh.rit.edu (Sean McGranaghan) writes: > > VDP Register Value Result > ------------- ----- ------------------------------------- > r0 >02 Set Mode bit 3 for bitmaped mode > > r1 >E0 default value > > r2 >06 Screen image table base address > >06 * >400 = >1800 > > r3 >80 Color table base address > >80 * >40 = >2000 > > r4 >00 Pattern descriptor table base address > >00 * >800 = >0000 > > r5 >36 Sprite attribute list base address > >36 * >80 = >1B00 > > r6 >07 Sprite descriptor table base address > >07 * >800 = >3800 > > r7 >07 default value > > > All of this should lead to VDP memory set up as follows: > > VDP Address Table Name Length > ----------- ---------- ------ > >0000 - >17FF Pattern descriptor table >1800 bytes > >1800 - >1AFF Screen image table >300 bytes > >1B00 - >1B7F Sprite attribute list >80 bytes > >1B80 - >1FFF free space >480 bytes > >2000 - >37FF Color table >1800 bytes > >3800 - >3BFF Sprite descriptor table >400 bytes > >3C00 - >3FFF free space >400 bytes Sean, the E/A manual is wrong, but the 1 page addendum explains many errors in it. Included is the correction for bit-map mode register settings. Pattern descriptor table: at >0000-17FF, r4 = >03 at >2000-37FF, r4 = >07 Color table: at >0000-17FF, r3 = >7F at >2000-37FF, r3 = >FF "Now why did TI do this?" you may ask. The simple explanation is that the bits in the registers correspond to video RAM address bits. Bit 2 (bit 5 in TI's big-endian numbering scheme) of r4 corresponds to the most significant bit of the video RAM address. Bit 7 (or TI's bit 0) of r3 corresponds to the most significant bit of the video RAM address as well. The value of the pattern descriptor table base address is the value in r4 of the meaningful bits shifted by 11 (or multiplied by 2048). The color table base address is the value in r3 of the meaningful bits shifted by 6 (or multiplied by 64). For bitmap mode, the meaningful bit of r4 gives a value of 0 or 4. Multiply by 2048 and you get 0 or 8192 (>0000 or >2000), respectively. The meaningful bit of r3 gives a value of 0 or 128. Multiply by 64 and you get 0 or 8192 (>0000 or >2000), respectively. Designing the TMS9918A (and V9938/V9958) this way simplifies the routing of the register values to address lines on the die. The other option would require routing different bits of r3 and r4 as the most significant bit of the video RAM address. The "unused" bits of r3 and r4 less significant than the used bits should be set to 1. This is so that the address lines these less significant bits correspond to do not have their values masked to 0. When you put >00 into r4, you were making A13, A12, and A11 of the pattern descriptor address always 0. This meant when the VDP was fetching >0000-07FF, it fetched the first 2048 bytes. Also, when the VDP was fetching >0800-0FFF, it was fetching >0000-07FF. Likewise with >1000-17FF. For the 9918A, the video address bits correspond to register bits as follows: r3 = A13 A12 A11 A10 A9 A8 A7 A6 r4 = 0 0 0 0 0 A13 A12 A11 Now you can do some weird things if you know that when you set one of the "unmeaningful" bits of r3 or r4 during bitmap mode to 0 you are in fact ANDing the corresponding address lines when said registers are used for a display fetch with 0, or effectively masking them to 0. So, you can cut the color table to 2048 bytes by setting A12 and A11 of r3 to 0, or putting the values >1F or >9F into it depending on where you want the base address to be. Using this undocumented functionality is what our good friend Eric Lafortune did in "Rock Runner" to get great graphic effects. I have also used this functionality to write a 64-column terminal emulator. With a full 6K pattern descriptor table, and 2K color table, there is 8K of video RAM left. This is enough to hold 8 screen image tables which can be quickly flipped for a scroll effect, with only the patterns for lines 7, 15, and 23 (new line) needing to be re-drawn in the pattern descriptor table. Of course, I could cut the color table down to 1K by masking an additional address bit (A10) to 0. In fact, I can cut it down to 64 bytes by making all of A12 to A6 bits in r3 to 0. Load all 64 bytes with the same two color code, such as >1F, and the entire screen will be black and white. However, just defining those 64 bytes is actually just defining the colors for 8 pixel lines of each 8 characters. Isn't this all very interesting? You can have a complete monochrome bitmap display with 6K for patterns, 64 bytes for colors, and 768 bytes for pattern position (screen image table). With the fast scroll, I was using in my 64x24 column terminal emulator eight separate screen image tables which must be put on 1K boundaries non-conflicting with pattern descriptor table or color table. The pattern descriptor table is put at >0000-17FF by loading r4 with >03. The color table is put at >2000-203F by loading r3 with >80. Two screen image tables are located at >1800-1AFF (r2=>06) and >1C00-1EFF (r2=>07). Six more can be located at >2400-26FF (r2=>09), >2800-2AFF (r2=>0A), >2C00-2EFF (r2=>0B), >3000-32FF (r2=>0C), >3400-36FF (r2=>0D), and >3800-3AFF (r2=>0E). To do the scroll takes some fairly complex programming, but setting up the eight screen image tables is a big and easy part of it. The first screen image table has >00-FF repeated three times. The second screen image table has >20-FF,>00-1F repeated three times. The third screen image table has >40-FF,>00-3F repeated three times. See the pattern? The eighth and last screen image table has >E0-FF,>00-DF repeated three times. The tricky part, and the part that slows the code down, is re-drawing the 8th, 16th, and 24th lines after a screen image table page flip. This is because the first line in the middle third of the screen must be scrolled to the last line of the top third of the screen. The first line of the last third of the screen must be scrolled to the last line middle third of the screen. The last line of the last third of the screen must be drawn over with the new line. Of course, I have written complex code to handle all this special scrolling. The 64 columns looks quite good with the right font. There is sufficient memory left of the 16K video RAM for disk I/O buffers and limited sprites. A TE can do without sprites (none in text mode TE's). There would be 256 bytes after each of the first seven alternate screen image tables. After the color table would be 960 contiguous bytes. After the eighth alternate screen image table would be 1280 contiguous bytes. A CALL FILES(2) equivalent would have room in that 1280 bytes to handle disk I/O. Jeff White p.s.: I typed this online in the VAX/VMS line editor, so any mistakes are not my fault. :^) -*- ============================================================================= DTIHM029 From: daven@vx.cis.umn.edu (David Nieters) Subject:v9938 Graphics 4 mode tutorial Part 1 Date: Fri, 2 Apr 1993 21:23:00 GMT Message-ID:<2APR199316233934@vx.cis.umn.edu> This is a tutorial for those of you with Geneves or 99/4A's with an 80 column (i.e. 9938) device attached to it. It is written for those who want to begin to learn how to use the more advanced featues of the V9938 that the 9918A does not offer. This is a tutorial on using the V9938 in Graphics 4 mode. In part 1, I will be explaining a program called LINES that was written for the 9918A processor to demonstrate it's graphic mode. This program came from TI with the Mini-Memory module. I will extend this program to use Graphics 4 mode. In later tutorials, we will try to increase the performance of this program using the V9938's build in commands. If there is sufficient interest, I will write parts two and three and post them as well. OVERVIEW OF GRAPHICS 4 MODE --------------------------- In Graphics 4 mode, there is no Pattern Generator Table like we have been used to in the 9918A. Instead, each pixel on the screen is controlled by a 4-bit color assignment in the Pattern Name Table. Therefore, each pixel can be one of 16 colors and each byte in the Pattern Name Table describes two pixels on the screen. The screen size is either 256 X 192 or 256 X 212 pixels depending on the LN bit of VDP register 9. Therefore, the Pattern Name Table will be 24,576 or 27,136 bytes respectively. The Pattern Name Table can be located in only four areas of memory. They are 0, >08000, >10000, >18000. The location is determined by Register #2. For this program, the Pattern Name Table will start at 0. OVERVIEW OF THE LINES PROGRAM ----------------------------- The lines program is in basically three parts. One part determines where the end points of each line will be. It then calls another part which draws a line between the end points. That part then calls another routine to plot each individual point. One pitfall that I encountered early on is addressing the VDP memory. The 9918A had a maximum of 16KB and therefore used only 14 bits to address all of it's memory. The 9918A has 128KB of memory, thus needing 17 bits to address all of its memory. When using the standard VDP memory routines (e.g. VSBW,VSBR,VMBW,VMBR), you can only access 16KB of memory. As we saw earlier, Graphics 4 mode uses over 24KB of memory. Before using the routines VSBW,VSBR,VMBW, and VMBR, you must make sure the three high order bits of the address are set in VDP register 14 first. Another problem I had was when writing repeatedly to VDPWD. Each time you write a byte of data, the VDP address gets incremented automatically. If you continually write past a 16KB boundry, R14 will get incremented so that the next time you make a call ro VSBW,VSBR,VMBW, or VMBR, it is acting on a different location in memory. Therefore, it is important to always write to VDP Register 14 before reading and writing VDP memory. Finally, it is important to set VDP Register 14 back to zero before exiting. If not, when the system is reset, it will begin to write in high areas of VDP memory and your title screen will not appear right without another reset. Now, on with the source code. If there are parts that are not clear, make a comment to me and I will try to clear it up in my next tutorial. REF VWTR,VSBW,VMBW,KSCAN,VSBR REF VDPWD,VDPWA,VDPSTA HEIGHT EQU 212 NUMBER OF LINES NUMLIN EQU 100 NUMBER OF LINES WE DRAW BEFORE ERASING SCREEN * CLEAR THE SCREEN * * THIS ROUTINE CLEARS THE SCREEN BY WRITING ZEROS IN THE * PATTERN NAME TABLE. WHEN DEALING WITH THE LARGER MEMORY * SPACE OF THE V9938, WE HAVE TO BE SURE THAT REGISTER #14 * IS CLEARED BEFORE WE START. OTHERWISE WE MIGHT BY ZEROING * OUT HIGHER AREAS OF MEMORY THAN WE WANT TO. * CLEAR LI R0,>0E00 RESET OUR VDP ADDRESS BLWP @VWTR LI R0,>0040 MOVB R0,@VDPWA SWPB R0 MOVB R0,@VDPWA LI R2,HEIGHT*128 WE WILL WRITE 24,576 ZEROS CLR R0 CLEAR1 MOVB R0,@VDPWD DEC R2 JNE CLEAR1 RT * RANDOM NUMBER GENERATOR * * THIS PROCEDURE RETURNS A (NOT SO) RANDOM NUMBER IN R1. * IT ENSURES THE RANDOM NUMBER WILL NOT BE 0. * RAND MOV @SEED,R1 RAND1 AI R1,>1D6B JEQ RAND1 MOV R1,@SEED RT SEED DATA >690A DX1 DATA 0 THESE LOCATIONS ARE USED TO STORE DX2 DATA 0 HOW FAR THE ENDPOINTS MOVE EACH DY1 DATA 0 TIME A LINE IS DRAWN DY2 DATA 0 * COLOR FLAG * * WHEN COLOR FLAG IS ZERO, THE LINES WILL APPEAR IN * DIFFERENT COLORS. WHEN IT IS NOT SET TO ZERO, ALL * LINES WILL BR DRAWN IN THE SAME COLOR. IT'S TOGGLED * BY PRESSING THE 'C' WHILE LINES ARE BEING DRAWN. * CFLAG DATA 0 * POINT * * POINT WILL TAKE AN X COORDINATE IN R0 AND A Y * COORDINATE IN R1 AND A COLOR IN R2 AND PLOT THAT * POINT ON THE SCREEN * POINT SLA R1,8 COMPUTE OFFSET IN PATTERN NAME TABLE A R1,R0 SRL R0,1 JOC POINT1 SEE IF LEFT HAND OR RIGHT HAND LI R3,>F000 MOV R2,R4 SLA R4,12 JMP POINT2 POINT1 LI R3,>0F00 MOV R2,R4 SLA R4,8 POINT2 MOV R0,R2 ANDI R0,>C000 WRITE UPPER 2 BITS OF ADDRESS SRL R0,14 TO VDP REGISTER 14 ORI R0,>0E00 BLWP @VWTR MOV R2,R0 ANDI R0,>3FFF BLWP @VSBR READ BYTE ALREADY THERE SZCB R3,R1 CLEAR OUT OLD COLOR SOCB R4,R1 PUT IN NEW COLOR BLWP @VSBW REWRITE OUT TO THE SCREEN RT * PLOT * * THIS ROUTINE PLOTS A LINE FROM (X1,Y1) TO (X2,Y2) * THESE COORDINATES ARE LOCATED IN THE CALLERS * REGISTERS R6,R7,R8 AND R9. THE COLOR IS * SPECIFIED IN THE CALLER'S R10. * PLOT DATA >8300 DATA PLOT1 PLOT1 CLR R12 LI R5,1 LI R6,1 MOV @16(R13),R7 MOV @12(R13),R9 S R9,R7 JLT PLOT11 JMP PLOT2 PLOT11 NEG R7 NEG R5 PLOT2 MOV R7,R7 JNE PLOT3 SETO R12 PLOT3 MOV @18(R13),R8 MOV @14(R13),R10 S R10,R8 JLT PLOT4 JMP PLOT5 PLOT4 NEG R6 NEG R8 PLOT5 MOV R9,R0 MOV R10,R1 MOV @10(R13),R2 GET COLOR BL @POINT C R9,@16(R13) JNE PLOT6 C R10,@18(R13) JNE PLOT6 RTWP PLOT6 MOV R12,R12 JLT PLOT7 A R5,R9 S R8,R12 JMP PLOT5 PLOT7 A R6,R10 A R7,R12 JMP PLOT5 * MAIN PROGRAM * START LWPI >8320 LI R2,VDPREG SET VDP REGISTERS L1 MOV *R2+,R0 JLT L2 BLWP @VWTR JMP L1 BL @CLEAR CLEAR THE SCREEN CLR @CFLAG CLR R3 R3 COUNTS THE NUMBER OF LINES WE HAVE DRAWN LI R6,>80 SET THE ENDPOINTS FOR OUR FIRST LINE LI R7,>60 LI R8,>D3 LI R9,>13 CLR R0 SET THE INITIAL AMOUNTS THE ENDPOINTS INCT R0 MOVE BY MOV R0,@DX1 INCT R0 MOV R0,@DY1 INCT R0 MOV R0,@DX2 INCT R0 MOV R0,@DY2 LOOP MOV @CFLAG,R0 JNE L5 BL @RAND PICK A RANDOM COLOR ANDI R1,>F MOV R1,R5 CI R5,2 MAKE SURE WE DON'T HAVE BLACK JHE L5 ORI R5,2 L5 A @DX1,R6 MOVE THE ENDPOINTS A @DY1,R7 A @DX2,R8 A @DY2,R9 * CHECK TO MAKE SURE THAT NO ENDPOINTS HAVE MOVED OFF * THE SCREEN. IF SO, REVERSE ITS DIRECTION. * MOV R6,R6 JLT L6 CI R6,>100 JLT L7 L6 NEG @DX1 A @DX1,R6 L7 MOV R8,R8 JLT L8 CI R8,>100 JLT L9 L8 NEG @DX2 A @DX2,R8 L9 MOV R7,R7 JLT L10 CI R7,HEIGHT JLT L11 L10 NEG @DY1 A @DY1,R7 L11 MOV R9,R9 JLT L12 CI R9,HEIGHT JLT L13 L12 NEG @DY2 A @DY2,R9 L13 BLWP @PLOT L14 CLR R0 CHECK TO SEE IF A KEY IS PRESSED MOVB R0,@>8374 BLWP @KSCAN MOVB @>8375,R0 MOVB @>837C,R1 JEQ L16 CI R0,>0500 CHECK FOR QUIT KEY JNE L15 B @QUIT L15 CI R0,>4300 CHECK FOR "C" KEY PRESSED JNE L14 INV @CFLAG TOGGLE THE COLOR FLAG L16 CI R0,>FF00 JNE L14 INC R3 CI R3,NUMLIN SEE IF WE HAVE MORE LINES TO DRAW JNE LOOP IF SO, GO BACK AND DRAW THEM CLR R3 LI R2,10 LI R4,>FFFF DLY DEC R4 WAIT A LITTLE BEFORE CLEARING THE SCREEN JNE DLY DEC R2 JNE DLY BL @RAND COMPUTE NEW RANDOM MOVEMENTS MOV R1,R1 JLT L17 ANDI R1,7 JMP L18 L17 ORI R1,>FFF8 L18 MOV R1,@DX2 BL @RAND MOV R1,R1 JLT L19 ANDI R1,7 JMP L20 L19 ORI R1,>FFF8 L20 MOV R1,@DY1 BL @RAND MOV R1,R1 JLT L21 ANDI R1,7 JMP L22 L21 ORI R1,>FFF8 L22 MOV R1,@DX1 BL @RAND MOV R1,R1 JLT L23 ANDI R1,7 JMP L24 L23 ORI R1,>FFF8 L24 MOV R1,@DY2 BL @CLEAR CLEAR SCREEN B @LOOP START OVER QUIT LI R2,REG2 RESTORE VDP REGISTERS BACK TO NORMAL QUIT1 MOV *R2+,R0 JLT QUIT2 BLWP @VWTR JMP QUIT1 QUIT2 LIMI 2 BLWP @0 * VDP REGISTERS TO SET VDP TO GRAPHICS 4 MODE * VDPREG DATA >0006 DATA >0160 DATA >021F LOCATE NAME TABLE AT ADDRESS 0 DATA >0711 SET BACKGROUND TO BLACK DATA >080A INHIBIT SPRITES DATA >0980 212 LINES DATA >FFFF * VDP REGISTERS WHEN WE EXIT * REG2 DATA >0000 DATA >0F00 DATA >01F0 DATA >0200 DATA >03FF DATA >0401 DATA >0560 DATA >0E00 DATA >FFFF END START ============================================================================= DTIHM030 In search of.... Leading Edge Connectors. by Dan H. Eicher A while back I was sourcing parts to finish a 99/8 P-Box interface card. For those of you who have looked at your cards, you may have noticed at one point or another certain cards having a black plastic edge connector. These are sort of rare. These connectors are called TI Leading Edge Connectors. They provide an alternative to just making and edge connector by printing traces on the bottom of the PCB. For a while TI was pushing these connectors on the electronics industry, of course these connectors never gained much popularity in the consumer market, because no one wanted to spend the few extra cents for quality goods. Note: These connectors are built to very high standards, they will survive many insert/extraction cycles and are designed to give maximum conductivity in a variety of situations. These connectors are also gold plated, as all good connectors should be. **** End of editorial **** Well I needed to buy one of these to finish my 99/8 interface card. Well after some calls to my local suppliers, Newark, Jameco ect... I came up empty..... Well after many MANY phone calls I got a hold of the TI division that makes these connectors. When I called six months ago, they were on the list to be obsoleted, but were still available. So if you want any of these connectors to repairs boards or place in your stock, you had better call now.... TI Part # L2111121-30 and the person to call is: Sue Rodgers 508.236.5375 Hope that this can save someone sometime! Dano L.D.O.M. 06.27.95 =========================================================================== DTIHM031 Modify the Rave Speech Card and MBP Card for use with the Geneve. by Beery Miller Item 7747642 94/05/05 23:20 From: BW.MILLER Beery W. Miller To: BW.MILLER Beery W. Miller COMP.SYS.TI.USENET@GATEKEEPER.DEC.COM@INET# Sub: To: Markus Kraemer Markus, here are the mods to the Rave Speech card and the MBP that permits full decoding of those cards to work with the Geneve. Any Geneve using one of those cards without these mods are subject to PROBLEMS, PROBLEMS, PROBLEMS. The mods for the Geneve compatibility is as follows: Solder pins 8 and pins 16 of a 74LS138 to pins 8 and 16 of 74LS138 on the card (this is for +5 volts and ground only, you may use another source if available), i.e. piggyback the chips. Now for the decoding mod that properly decodes the Rave Speech card and the MBP card for full Geneve Compatibility (these devices will only respond at page >BC) Cut the trace of pin 56 on the card near the bus connector Pins of 74LS138 _____________________________________________________________- 1 Connect to bus pin 46 2 Connect to bus pin 45 3 Connect to bus pin 48 4 Connect to bus side of bus pin 56 5 Connect to bus pin 8 6 Connect to bus pin 9 7 Connect to component side of bus pin 56 8 Connect to pin 8 of 74LS138 16 Connect to pin 16 of 74LS138 (pins 9 through 15 are left disconnected) These modifications are done at your own risk. You assume all responsibilty for performing these modifications. ========================================================================== DTIHM032 Here is the pin definition for the new Rave expansion box. For further information you can contact: RAVE 99 Co. Attn: John McDevitt 112 Rambling Road Vernon, CT 06066 (203)-871-7824 I have "transcribed" this information from the manual that comes with the Rave p-box. Any errors are my own. Hope this information helps. Dan H. Eicher Delphi: EICHER Looking into connector from the component side - pin 1 towards rear of chassis. ____ Plus 12 Volts Reg. +12V 2 = = 1 +12V Plus 12 Volts Reg. Ready A READY A 4 = = 3 GND Logic Ground Computer Reset RESET 6 = = 5 GND Logic Ground System Clock SCLK 8 = = 7 GND Logic Ground Audio AUDIO 10 = = 9 LCP CPU Indicator PCB Enable PCBEN 12 = = 11 RBDENA Remote Data Bus Control IAQ Hold A IAQHA 14 = = 13 HOLD CPU Hold Request Inter. Level B SENILB 16 = = 15 SENILA Inter. Level A Sense Enabl Load Interrupt LOAD 18 = = 17 INTA Inter. Level A Logic Ground GND 20 = = 19 D7 System Data Bit 7 System Data Bit 6 D6 22 = = 21 D5 System Data Bit 5 System Data Bit 4 D4 24 = = 23 D3 System Data Bit 3 System Data Bit 2 D2 26 = = 25 D1 System Data Bit 1 System Data Bit 0 D0 28 = = 27 GND Logic Ground System Address Bit 15 A15/CRU 30 = = 29 A14 System Address Bit 14 System Address Bit 13 A13 32 = = 31 A12 System Address Bit 12 System Address Bit 11 A11 34 = = 33 A10 System Address Bit 10 System Address Bit 09 A09 36 = = 35 A08 System Address Bit 08 System Address Bit 07 A07 38 = = 37 A06 System Address Bit 06 System Address Bit 05 A05 40 = = 39 A04 System Address Bit 04 System Address Bit 03 A03 42 = = 41 A02 System Address Bit 02 System Address Bit 01 A01 44 = = 43 A00 System Address Bit 00 System Address Bit A AMA 46 = = 45 AMB System Address Bit B System Address Bit C AMC 48 = = 47 GND Logic Ground CPU Clock CLKOUT 50 = = 49 GND Logic Ground DATA Bus Direction DBIN 52 = = 51 CRUCLK CRU Clock CPU Write Enable WE 54 = = 53 GND Logic Ground Memory Request MEMEN 56 = = 55 CRUIN CRU Input Data Minus 12 Volts Reg. -12V 58 = = 57 -12V Minus 12 Volts Reg. Plus 12 Volts Reg. +12V 60 = = 59 +12V Plus 12 Volts Reg. ---- ____ Plus 5 Volts Reg. +5v 2 = = 1 +5V Plus 5 Volts Reg. Minus 12 Volts Reg. -12v 4 = = 3 -12V Minus 12 Volts Reg. Sound Out Geneve SNDOUTG 6 = = 5 GENSEL Geneve/4A Select Line Key Lock Switch KEYLSW 8 = = 7 VIDOUTG Video Out Geneve Extra Bit #10 XB10 10 = = 9 XB9 Extra Bit #9 System Address Bit G AMG 12 = = 11 AMF System Address Bit F System Address Bit I AMI 14 = = 13 AMH System Address Bit H System Address Bit K AMK 16 = = 15 AMJ System Address Bit J System Address Bit M AMM 18 = = 17 AML System Address Bit L Logic Ground GND 20 = = 19 D15 System Data Bit 15 System Data Bit 14 D14 22 = = 21 D13 System Data Bit 13 System Data Bit 12 D12 24 = = 23 D11 System Data Bit 11 System Data Bit 10 D10 26 = = 25 D9 System Data Bit 09 System Data Bit 08 D8 28 = = 27 GND Logic Ground Keyboard Data Geneve KBDAT 30 = = 29 KBCLK Keyboard Clock Geneve Turbo Switch TURBO/SW32 = = 31 RESETSW Reset Switch Minus 5 Volts Reg. -5V 34 = = 33 -5V Minus 5 Volts Reg. Plus 12 Volts Reg. +12V 36 = = 35 +12V Plus 12 Volts Reg. ---- The following is an editors note: For comparision the max for the different voltage lines on a "typical" IBM type 200 watt switching power supply is: +5V 20A -5V 0.5A +12V 8A -12V 0.5A The "Standard" TI power supply has the following ratings (per the Bunyard Manual): .5 Amps per card slot is available from the +5V .25 " " " " " " " " +12V 50 ma " " " " " " " -12V These calculations include a debit for the internal disk drive from the power supplies total capability. ============================================================================== DTIHM033 TI-99/4 - THE EARLY DAYS by Chuck Neal Portland Users Ninety Niners Here is an interesting bit of TI history that came over the UNIX user net at work. I rearranged some of the material for clarity. The contributor of this article was Herbert H. Taylor of the David Sarnoff Research Center. It appears that he worked at Texas Instruments back in the late 1970's when the TI-99 "Was Happening." First you will find out what the "pack-man door" on your speech synthesizer is for (was for!). Next he talks about some mysterious "wireless peripherals" that the TI 99/4 almost had. Then the replacement of the 9985 microprocessor by the 9900 and the suggestion that there are a lot more intersting stories waiting to be told! The last part of the article goes into the history of the RF modulator. In the early days you had to hook your TI into a television set, and television sets don't have audio and video inputs - they have radio frequency inputs. (Except for some of the new ones). So the RF modulator is like a miniature TV broadcasting station, broadcasting on channel 3. SPEECH SYNTHESIZER The plug-in port on the speech module was intended to expand the number of permanent words of vocabulary as in Speak-N-Spell. When TE-II worked better than expected, TI lost interest in expansion modules. It is possible that only the first few thousand speech modules have the "hooks" for those modules. I own several vintage speech modules and they all have the hooks, but I never got any plug-in modules and I designed the interface...(Please, no questions, it's been 11 years!) WIRELESS PERIPHERALS Another historical note: the first few thousand orginal 99/4's had a hidden plug in slot on the top flat surface ( under the metal overlay) for an IR ( Infer-Red ) remote control transmitter/receiver about the size of a Kodak Instamatic. This device supported a number of never introduced wireless peripherals - including a wireless "super" keyboard and joystick. The wireless peripherals were supported on the systems shown at the June 1979 CES show in Chicago. Ten minutes before the introductory press conference, we were told "...not to show the peripherals..." In any event I am fairly certain the software support for these peripherals was left in GROM - at least until the switch to the 99/4A, which included the new (actually the "original") keyboard. These peripherals were never introduced because TI thought that they were too expensive for a Home Computer with an intended 1979 price of uner $100. (When Apple was $2000) When the price "skyrocketed" to $1000, it was supposedly "too late" to bring out the wireless peripherals. The price increase was due to the complete failure of the cheap TMS9985 microprocessor orginally designed into the 99/4. This resulted in changing over to a very expensive goldlead ceramic packaged TMS9900, a TTL clock driver, a 256 byte static RAM, and a ton of TTL glue logic. (The true story of how the 9900 ended up in the 99/4 would rival General Hospital!) VIDEO MODULATOR Also the first few hundred units had the "hooks" to bring in external video and genlock the TMS9918 - a capability which even today is not generally found in personal computers. This was removed from the connector (despite its less than $1.00 cost in parts) because at the time of the 99/4 introduction, the interface had not been tested sufficiently and there was still too much unvertainty about the FCC implications of genlocking a class 1 TV device. Remember at the time (1979), any TV game or computer that had an RF modulator had to pass very strict FCC testing. The 99/4 orginally had a built-in RF modulator, which was removed shortly before the June 1979 CES show when the decision was made to package the 99/4 with the Zenith color monitor. In 1978 we built 200 prototype 99/4's with built-in RF modulators and a 9900 "emulation" of the 9985 on a 9"x4" board sandwhiched onto the original PWB and crammed into the orginal 99/4 tooled case. These 200 units were given to TI executives and board members to play with for six months. I have a wire-wrapped proto type with one of the few 9985's ever produced, but I would be interested in acquiring any of the 200 prototypes which might be existant. Everyone was quite shocked when the FCC ruled in TI's favor. That ruling distinguished personal computers from video games. The decision to remove the RF modulator from the console was initiated when the FCC agreed to test a fiber optic interface we had developed. This optically coupled the computer console with a standalone RF modulator. This interface was dubbed the "video light pipe". After the system was sent to the FCC they returned in UNTESTED, stating that they could not accept petitions for rule making to modify existing rules. The rest is history. L.D.O.M. 11.25.94 ============================================================================== DTIHM034 9900,9901,9902,9904 by Definitions by Dan Eicher ___ ___ VBB 01 =| U |= 64 HOLD - * Note Pins with a - before or VCC 02 =| |= 63 MEMEN - after them represent active WAIT 03 =| T |= 62 READY lows. -LOAD 04 =| M |= 61 WE HOLDA 05 =| S |= 60 CRUCLK -RESET 06 =| |= 59 VCC IAQ 07 =| 9 |= 58 NC u1 08 =| 9 |= 57 NC u2 09 =| 0 |= 56 D15 A14 10 =| 0 |= 55 D14 A13 11 =| |= 54 D13 A12 12 =| |= 53 D12 A11 13 =| |= 52 D11 A10 14 =| |= 51 D10 A09 15 =| |= 50 D09 A08 16 =| |= 49 D08 A07 17 =| |= 48 D07 A06 18 =| |= 47 D06 A05 19 =| |= 46 D05 A04 20 =| |= 45 D04 A03 21 =| |= 44 D03 A02 22 =| |= 43 D02 A01 23 =| |= 42 D01 A00 24 =| |= 41 D00 u4 25 =| |= 40 VSS VSS 26 =| |= 39 NC VDD 27 =| |= 38 NC u3 28 =| |= 37 NC DBIN 29 =| |= 36 IC0 CRUOUT 30 =| |= 35 IC1 CRUIN 31 =| |= 34 IC2 -INTREQ 32 =|_____|= 33 IC3 ___ ___ RST1 01 =| U |= 40 VCC CRUOUT 02 =| |= 39 S0 CRUCLK 03 =| T |= 38 P0 CRUIN 04 =| M |= 37 P1 -CE 05 =| S |= 36 S1 -INT6 06 =| |= 35 S2 -INT5 07 =| 9 |= 34 -INT7/+P15 -INT4 08 =| 9 |= 33 -INT8/+P14 -INT3 09 =| 0 |= 32 -INT9/+P13 -u 10 =| 1 |= 31 -INT10/+P12 INTREQ 11 =| |= 30 -INT11/+P11 IC3 12 =| |= 29 -INT10/+P10 IC2 13 =| |= 28 -INT09/+P09 IC1 14 =| |= 27 -INT08/+P08 IC0 15 =| |= 26 P2 VSS 16 =| |= 25 S3 -INT1 17 =| |= 24 S4 -INT2 18 =| |= 23 -INT15/+P7 P6 19 =| |= 22 P3 P5 20 =| |= 21 P4 ------- ___ ___ -INT 01 =| U |= 18 VCC Note: This chip can be replaced with XOUT 02 =| T |= 17 -CE a 9903. The 9903 is identical RIN 03 =| M |= 16 -u except it also includes the CRUIN 04 =| S |= 15 CRUCLK ability to handle sync. commun- -RTS 05 =| |= 14 S0 ication. -CTS 06 =| 9 |= 13 S1 -DSR 07 =| 9 |= 12 S2 CRUOUT 08 =| 0 |= 11 S3 VSS 09 =| 2 |= 10 S4 ------- ___ ___ TANK1 01 =| U |= 20 VCC Note: This chip is also called a TANK2 02 =| T |= 19 XTAL2 74LS GND1 03 =| M |= 18 XTAL1 FFQ 04 =| S |= 17 OSCIN FFD 05 =| |= 16 OSCOUT u4 TTL 06 =| 9 |= 15 TTL u2 u3 TTL 07 =| 9 |= 14 TTL u3 u3 08 =| 0 |= 13 VDD u4 09 =| 4 |= 12 u1 GND 10 =| |= 11 u2 ------- ============================================================================= DTIHM035 Console Connectors by Thierry Norspikel From: Thierry Nouspikel <nouspike@cmu.unige.ch> Subject: Re: Article. In-reply-to: <01ICOTL7T8WY973IFF@delphi.com> CASSETTE TAPE FORMAT Name # of bytes Content ---------------------------- File sync 768 >00 Data mark 1 >FF Size 1 # of records Repeat size 1 dito Rec sync 8 >00 } Data mark 1 >FF } Rec 1 Data 64 data bytes } Checksum 1 sum of the 64 data bytes } Repeat rec 1 Rec 2 Repeat rec 2 etc. Bits are encoded by output level CHANGES. With a 3 MHz console, clock ticks toggle output every 725.3 microseconds. To encode a 1 invert the output in the middle of this time period. This results in frequencies of 689.37 Hz for a space (0) and 1379 Hz for a mark (1) which is well within the audio range, thus suitable for a tape player. 0 _1 _0_ 1_ Bits to encode !___! !_! !_! !_ Output (low/high) c c c c c Clock intervals NB: Upon writing, the timing is ensured by loading >0011 into the clock register of the TMS9901 chip. The resulting delay is 17 / (3MHz/64)=363.6 usec Upon reading, the stretches of zeros are used to time the tape recorder and this value is fed into the TMS9901 for further reading. ------------------------------------------------------------------------------- WHAT'S THE PINOUT OF THE ..... CONNECTOR ? Replace the ..... with: Joystick port, Cassette port, Main power port, Monitor port, Cartridge port, Peripheral port, Keyboard connector (internal) or Card slots (in PE box). These informations have been extracted from: TI-99/4A Console and Peripheral Expansion System Technical Data a very usefull handbook published by TI in 1983, with many informations, timing diagrams, console schematics, etc. ___________ Joystick port: ( 1 2 3 4 5 ) ============= \ 6 7 8 9 / # I/O Use \_______/ ----------- 1 not used 2 > Test joystick 2 3 < Up 4 < Fire button pressed 5 < Left 6 not used 7 > Test joystick 1 8 < Down 9 < Right ___________ cassette port: ( 1 2 3 4 5 ) ============== \ 6 7 8 9 / # I/O Use \_______/ ----------- 1 > Cass 1 motor control (CRU bit 22) 2 > Dito (neg) 3 > Output to tape 2 (CRU bit 25) 4 > Audio gate (CRU bit 24) 5 > Output to tape 2 (neg) 6 > Cass 2 motor control (CRU bit 23) 7 > Dito (neg) 8 < Input from tape 1 or 2 (CRU bit 27) 9 < Dito (neg) N.B. Cassette 1 can't be written to. Power port: =========== _________ Inside console (regulated) : < 1 2 3 4 | --------- # Volts -------- 1 -5 2 +12 3 GND 4 +5 The pinouts for the external plug look like this: >___ ___> >--1 (red) )!( 2 )!( 2 )!( 0 )!(---> >--2 (white) V )!( ~ )!( >___)!(___> >--4 (black) transformer >--3 (nc) NB: for US users replace 220V with 110V The AC values on pins 1, 2 and 4 appear to vary according to the model of transformer. Thus I did not idicate them here. Monitor port: 3 U 1 (This is a round plug, with a notch U at top) ============= 5 4 # Use 2 ------ 1 12V vid 2 R-Y (color burst clock) 3 Sound output 4 Y 5 B-Y (external video input?) U GND Cartridge port: =============== ______________________________________________________________ | 2 36 | | [====================] | |_______________________________________1__________________35__| |___|___|___|___|___|___|___|___|___|_| | |_____|___|___|___|___|___|___|___|___| | |___|___|___|___|___|___|___|___|_____| | |_____|___|___|___|___|___|___|___|___| | |___|___|__________________|___|______|________________________| # Name I/O Use - ---- --- ----------- 1 RESET < Resets the system (active high) 2 GND Signal groud 3 D7 <> Data bus, bit 7 (least significant) 4 CRUCLK* > Inversion of TMS9900 CRUCLOCK pin 5 D6 <> 6 CRUIN < CRU input to TMS9900 7 D5 <> 8 A15 > Address bus, bit 15 / also CRU output bit 9 D4 <> 10 A13 > 11 D3 <> 12 A12 > 13 D2 <> 14 A11 > 15 D1 <> 16 A10 > 17 D0 <> Data bus, bit 0 (most significant) 18 A9 > 19 VCC +5 Volts power supply 20 A8 > 21 GS* > Grom select. Active low is addr in >9800-9FFF 22 A7 > 23 A14 > Address bus, bit 14. Select mode: low=data / high=addr 24 A3 > 25 DBIN > Active high = read memory 26 A6 > 27 GRC > GROM clock: color burst of VDP 9918A 28 A5 > 29 VDD -5 Volts power supply 30 A4 > 31 GR < Active high = GROM ready 32 WE* > Active low = write enable (derived from TMS9900 WE*) 33 VSS 34 ROMG* > Active low if addr in >6000-7FFF 35 GND 36 GND Side port: (peripheral connector) ========== __________________________ / | / | ____________________________/ 2 44 | / [================] | / 1 43 | |__________________________________________________________| # Name I/O Use - ---- --- ----------- 1 VCC +5 Volts power supply 2 SBE > Low if addr in >9000-94xx (sound port) 3 RESET* > System reset (active low) 4 EXTINT* < External interrupt (active low) 5 A5 > Address bus, bit 5 6 A10 > 7 A4 > 8 A11 > 9 DBIN > Active high = read memory 10 A3 > 11 A12 > 12 READY < Active high = memory is ready 13 LOAD* < Unmaskable interrupt (=> BLWP @>FFFC) 14 A8 > 15 A13 > 16 A14 > 17 A7 > 18 A9 > 19 A15 > Address bus, lsb. Also CRU output bit. 20 A2 > 21 GND 22 CRUCLK* > Inversion of TMS9900 CRUCLOCK pin 23 GND 24 PHI3* > Inversion of phase 3 clock 25 GND 26 WE* > Write Enable (derived from TMS9900 WE* pin) 27 GND 28 MBE* > Active low if addr in >4000-5FFF (card ROMs) 29 A6 > 30 A1 > 31 A0 > Address bus, bit 0 (most significant) 32 MEMEN* > Memory access enable (active low) 33 CRUIN < CRU input bit to TMS9900 34 D7 <> Data bus, bit 7 (least significant) 35 D4 <> 36 D6 <> 37 D0 <> Data bus, bit 0 (most significant) 38 D5 <> 39 D2 <> 40 D1 <> 41 IAQ > Interrupt acknowledged by TMS9900 42 D3 <> 43 VDD -5 Volts power supply 44 AUDIOIN < To sound generator AUDIO IN pin Keyboard connector: (inside the console) Red wire is #15 =================== pin| 12 13 14 15 9 8 6 ---+------------------------------------------------------------- 5 | = . , M N / 4 | space L K J H ; 1 | enter O I U Y P 2 | 9 8 7 6 0 7 | fctn 2 3 4 5 1 lock 3 | shift S D F G A 10 | ctrl W E R T Q 11 | X C V B Z Note: pressing a key closes the contact between corresponding row + column. Since there are no diodes to prevent current going backwards, pressing 3 keys at a time often results in appearance of a "phantom" key at the 4th corner of the square formed by these keys (e.g 8+7+3=phantom 4: current goes pin15-7-8-3-pin7 as if 4 were pressed) Card slots: (inside the PE box) =========== 59 Left 1 Front ===================== Rear 60 Right 2 # Name I/O Use - ---- --- ----------- 1 +5V 3-T regulator voltage supply (about +8V) 2 Dito 3 GND 4 READYA System ready (10K pull-up to +5V) 5 GND 6 RESET* > System reset (active low) 7 GND 8 SCLK nc System clock (not connected) 9 LCP* nc CPU indicator 1=TI99 0=2nd generation (not connected) 10 AUDIO < Input audio (=AUDIOIN) 11 RDBENA* < Active low: enable flex cable data bus drivers (1K pull-up) 12 PCBEN H PCB enable for burn-in (always High) 13 HOLD* H Active low CPU hold request (always High) 14 IAQHA nc IAQ [or] HOLDA (logical or) 15 SENILA* H Interrupt level A sense enable (always High) 16 SENILB* H Interrupt level B sense enable (always High) 17 INTA* < Active low interrupt level A (=EXTINT*) 18 LOAD* nc Unmaskable interrupt (not connected) 19 D7 <> Data bus, bit 7 (least significant) 20 GND 21 D5 <> 22 D6 <> 23 D3 <> 24 D4 <> 25 D1 <> 26 D2 <> 27 GND 28 D0 <> Data bus, bit 0 (most significant) 29 A14 > 30 A15 > Address bus, lsb. Also CRU output bit. 31 A12 > 32 A13 > 33 A10 > 34 A11 > 35 A8 > 36 A9 > 37 A6 > 38 A7 > 39 A4 > 40 A5 > 41 A2 > 42 A3 > 43 A0 > Address but, bit 0 (most significant) 44 A1 > 45 AMB H Extra address bit. Always High. 46 AMA H Extra address bit. Always High. 47 GND 48 AMC H Extra address bit. Always High. 49 GND 50 CLKOUT* > Inversion of phase 3 clock (=PHI3*) 51 CRUCLK* > Inversion of TMS9900 CRUCLOCK pin 52 DBIN > Active high = read memory 53 GND 54 WE* > Write Enable (derived from TMS9900 WE* pin) 55 CRUIN < CRU input bit to TMS9900 56 MEMEN* > Memory access enable (active low) 57 -12 Volts 3-T regulator supply voltage (about -16V) 58 Dito 59 +12 Volts 3-T regulator supply voltage (about +16V) 60 Dito Notes: o Signals buffered by 74LS244 in connection card: A0-A15, DBIN, MEMEN*, WE*, CLRCLK*, RESET*, CLKOUT. o Unbuffered signals: CRUIN, INTA*, AUDIOIN, READY o Data bus is buffered by two 74LS245 (one at each end of the cable), driven by RDBENA (direction set by DBIN). o All signals must be re-buffered on each card. o Always High lines (AMA, AMB, AMC, SENILA*, SENILB*, PCBEN, HOLD*) are pulled up to +5 Volts by 47 Ohms resistors. o Connection card light is turned on by DBIN (High = on). Thierry Nouspikel, MD, PhD | "Un technocrate c'est un mec, Department of Biological Sciences | tu lui poses une question, Stanford University | quand il a fini de repondre Phone: 1 415 723 2425 | tu comprends plus ta question". Fax: 1 415 725 1848 | Michel Colucci, dit "Coluche" Email: thierry.nouspikel@stanford.edu | ============================================================================ DTIHM036 How to adapt Atari joystick to work on the TI. Author Unknown TI Joystick pins Atari Joystick Pins -- -------- ---- ----- -------- ---- 1) N.C. ------------1) Up S 2) Stick B--| | ----------2) Down t Ground | | | --------3) Left i 3) Up-----------+ | | --4) Right c 4) Fire---------|-|-|-| | 5) N.C. k Button | | | | +-----6) Fire btn 5) Left---------|-|-+ | | 7) N.C. B 6) N.C. |---|-|-|-|---|-8) Ground 7) Stick A--------------- | 9) N.C. Ground | | | | | | 8) Down-------- --|-|-|-|-|-1) Up S More? 9) Right---| |---+-|-|-|-|-2) Down t ---------+-------3) Left i [Female] | | --4) Right c | | 5) N.C. k --|---6) Fire btn | 7) N.C. A ----8) Ground 9) N.C. ============================================================================ DTIHM037 GRAND RAM Technical Specifications Last Update: August 14, 1987 GRAND RAM TECHNICAL DATA INTRODUCTION SECTION 1 The GRAND RAM card is designed to provide as many features as possible, while still keeping the cost reasonable. GRAND RAM provides the following features: 1. 512K bytes of battery-backed CMOS memory for RAM Disk, print spooling, text editing. The memory is expandable in increments of 32K bytes, using 256K bit static RAM chips (32K X 8 ). All memories are socketed, so no soldering is required for the full 512K capability. 2. Optional real-time clock allows time-stamping of files, clock access from BASIC, X-BASIC, assembly. 3. Two expansion ports, each with different capabilities: a. The Cartridge Emulator Port (CEP) provides all the signals required to support an add-on board which will emulate 99% of the cartridges in existence. The add-on board plugs into the 46 pin, dual-row, .025" square post header mounted on the GRAND RAM card. b. The Device Expansion Port (DEP) provides all the signals required to implement a variety of novel peripherals for the 99/4A, including: multiple channel music boards, A/D D/A capability with digital echo and reverberation, temperature logging, home control, etc. The device port add-on boards will plug into a 38 pin, dual-row, .025" square post header on the GRAND RAM card. 4. The technical specifications for these expansion ports are provided. GRAND RAM provides a great opportunity for hobbyists to do their own hardware projects. Most of the bus interface and decode circuitry is already provided by GRAND RAM, which makes device interfacing very simple. 5. A Programmable Interrupt Timer, which provides the capability for print spooling, hot keys (with the proper software), as well as providing programmable timing pulses to the Device Expansion Port. 6. Hardware Write Protect feature reduces the chances of a runaway program trashing the DSR. Designed by Sofmachine Inc. 1-1 Copyright 1987 DataBioTics GRAND RAM TECHNICAL DATA GRAND RAM Architecture SECTION 2 All memories and devices are accessed through the DSR address space of the 99/4A, which is the 8K block from >4000 to >5FFF, and the CRU space. The CRU base address is dependent upon some DIP switch settings. Some of the CRU bits are used to control access to the memory and memory-mapped I/O devices. The 512K RAM memory is accessed in 2K pages. 1. CRU Base Address for GRAND RAM - Setting the DIP Switches Switches 1, 2, and 3 of the 4-section DIP switch are used to determine the CRU address at which GRAND RAM responds. Any one of seven CRU addresses may be selected. Since the disk controller card uses the CRU slot at >1100 and the RS232 card uses the slot at >1300, these addresses are not available for GRAND RAM. The following table details the CRU addresses for all switch settings. DIP Switch/CRU Address Chart --------------------------------------------- | SW1 SW2 SW3 | CRU Address | --------------------------------------------- | ON ON ON | >1000 | | ON ON OFF | >1200 | | ON OFF ON | >1400 | | ON OFF OFF | >1500 | | OFF ON ON | >1600 | | OFF ON OFF | >1700 | | OFF OFF ON | >1800 | | OFF OFF OFF | GRAND RAM DISABLED | --------------------------------------------- 2. CRU Bits for Memory Control In order to access the DSR memory address space, the first CRU bit (CRUBIT0) in the GRAND RAM's CRU space must be set to a 1. The second CRU bit (CRUBIT1) is the Write Protect bit (1=Write Protected), which dissallows all writes to the memory space of GRAND RAM. The memory- mapped I/O devices are accessed at locations >4F00 - >4FFF. In order to access these mem-mapped I/O devices, the third CRU bit (CRUBIT2) must set to zero. If CRUBIT2 = 1, then memory is present at >4F00 - >4FFF. Designed by Sofmachine Inc. 2-1 Copyright 1987 DataBioTics GRAND RAM TECHNICAL DATA GRAND RAM Architecture 3. RAM Memory Access Mapping The first two 2K blocks of GRAND RAM memory (4K total) are permanently mapped into the first 4K bytes of the DSR space (>4000 - >4FFF). However, the 256-byte RAM block from >4F00 to >4FFF and the I/O devices are swapped in and out using CRUBIT2 as described above. The second 4K bytes of DSR memory space (>5000 - >5FFF) are used to access selected blocks of GRAND RAM memory. This second 4K space is split in half: the first memory space starts at >5000 and the second at >5800. The specific blocks of GRAND RAM memory which are mapped into these two address spaces are defined by two 8-bit, write-only, page registers. This "dual-window" architecture allows two different blocks of GRAND RAM memory to be accessed without banking. 4. Onboard I/O Device Mapping There are only four active I/O device locations on the GRAND RAM board. Two are the write-only memory page registers (discussed above) and the remaining two are the read and write locations for the real-time clock. The address and function of each device location is described below, as well as the required value of CRUBIT0 thru CRUBIT2 when accessing these devices. CRU I/O Map Address CRUBIT0 CRUBIT1 CRUBIT2 Function ----------------------------------------------------------------------- >4FE0 1 0 0 Selects which 2K page of GRAND RAM memory is mapped into the address space from >5000 to >57FF. >4FE2 1 0 0 Selects which 2K page of GRAND RAM memory is mapped into the address space from >5800 to >5fFF. >4FE4 1 0 0 Write to the Real-time Clock >4FE6 1 0 X Read from the Real-time Clock 5. TMS9901 Interval Timer I/O Peripheral The TMS9901 is a peripheral designed specifically for the 9900 family of microprocessors, and contains: 16 general-purpose I/O lines, 6 interrupt lines (also usable simply as input lines), a timer with 21.3 uS resolution and interrupt capability. The 9901 occupies 32 bits of CRU space, starting at the CRU base selected by the GRAND RAM DIP switches. IMPORTANT NOTE TO ALL PROGRAMMERS AND DEVELOPERS: the CRU bit addresses have been modified slightly such that the top and bottom halves of the 9901 CRU bit mappings have been swapped. This means that the I/O bits start at CRU bit 0 and the clock/interrupt bits start at CRU bit 16. This was done so that the first I/O bit could be used to enable/disable GRAND RAM and still be compatible with the 99/4A DSR lookup protocol, which uses CRU bit 0 to enable or disable a given DSR memory space. Due to the sophisticated nature of the 9901, a full discussion of it's capabilities is beyond the scope of this document. The reader desiring this information should refer to the TMS9901 Programmable Systems Interface booklet, or the 9900 Family Systems Design handbook, both published by Texas Instruments. Designed by Sofmachine Inc. 2-2 Copyright 1987 DataBioTics GRAND RAM TECHNICAL DATA GRAND RAM Architecture 6. Real-time Clock Access The clock chip which is compatible with GRAND RAM is the Dallas Semiconductor DS1215. Access to the chip is through the clock read and write addresses, specified above. The clock is accessed through a 1-bit interface which is connected to the most significant bit, DB7, of the buffered P-box data bus. Timekeeping features include: time resolution of timekeeping. For complete programming information, consult the DS1215 data sheet. 7. Interrupts GRAND RAM provides full interrupt capability, controlled by the TMS9901. There are two possible sources of interrupts: a. The 9901 Interval Timer can be programmed to interrupt on level 3. If the interval Timer interrupt is enabled, the INT3 line is disabled. b. The six external interrupt pins which are connected to the Device Expansion Port may cause an interrupt if the proper option board is attached. The interrupt 1 input (-INT1) has an onboard pullup resistor. All interrupt control is as described in the TMS9901 manual, with the exception of one extra level of hardware masking. No interrupts will occur on the 99/4A PEB bus unless CRUBIT3 is set to a zero. This allows the interval timer to be used as a precisely controlled hardware strobe for option boards connected to the Device Expansion Port, without actually generating an interrupt to the CPU. After power-up CRUBIT3 is set high, thus disabling 9901 interrupts to the CPU until explicitly enabled by the software. Designed by Sofmachine Inc. 2-3 Copyright 1987 DataBioTics GRAND RAM TECHNICAL DATA Hardware Design SECTION 3 The hardware to implement GRAND RAM is very modular. All IC's perform one or memory, multiplexer, register, miscellaneous logic. 1. Buffering Initially, the address, control, and data lines from the peripheral bus are buffered by 74LS244 (Address Control) and 74LS245 (Data) bus driver chips. 2. Miscellaneous Logic To ensure that addresses are stable when MEMEN is asserted, the leading edge of MEMEN is synchronously delayed for approximately 135 nS. This is accopmplished with an inverter (74LS05), and a D flip-flop (74LS74) which is clocked by the phase 3- bus clock. 3. Decoding/PALs A delayed version of MEMEN (described earlier) and the buffered control and address lines are the inputs to the two PALS. These PALs provide the signals required for controlling GRAND RAM. The following signals and functions are provided by the PALs: a. Clock strobes for the two 8-bit memory page registers. b. Output enable strobes for the two 8-bit memory page registers. c. Enable strobe for the two 74LS138 memory chip select decoders. d. Chip select for RAM chip #0. e. Chip select for the Real-time clock chip. f. Chip select for the TMS9901 peripheral chip. g. Multiplex control for >4000 - >4FFF RAM access. h. Protected Write Enable for RAMs. i. Local data bus enable control. j. Buffered tri-state remote data bus enable. k. Pre-decoded GRAM signal for future cartridge emulation. l. Pre-decoded Expansion I/O strobe (-EXPIO). 4. Page Registers The two page registers are implemented with octal, edge-clocked latches with tri-state outputs (74LS374). The register output enable controls are used to select which page register is addressing the GRAND RAM memory, thus providing a zero-chip multiplexing function. 5. Special Functions The TMS9901 peripheral interface is straitforward, except for the transposed top and bottom internal mapping. This is implemented by inverting the most significant address line (BA10) to the 9901. The real-time clock chip is mapped so that no unprogrammed accesses can occur, which is a hazard due to the 9900 read-before-write bus timing. Designed by Sofmachine Inc. 3-1 Copyright 1987 DataBioTics GRAND RAM TECHNICAL DATA Hardware Design 6. Memory The memory chips are 32K X 8 SRAMs, and are connected to a fully buffered bus. Also, the chip select and write enable lines are pulled up during power down to minimize standby power consumption. Chip select decoding is provided by two 74LS138 decoders. During any accesses to GRAND RAM at addresses >4000->4FFF, the first 4K of RAM chip #0 will always be selected. Half of a 74LS244 buffer is used to force the address to the first 4K of a memory chip, and the PAL always selects RAM chip #0 during accesses to >4000->4FFFF. During accesses to >5000-57FF, page register #0 addresses both the RAMs and chip select decoders, causing the appropriate 2K page to be selected. Accesses to >5800->5FFF cause page register #1 to select a 2K page, in the same manner as page register #0. 7. Power Supply Grand Ram contains two seperate power busses. The first, the logic power bus, supplies power to all the TTL and PAL chips. The RAMs and clock chip recieve power from the memory power bus. The memory power bus must supply power when the P-box is turned off. Diode D3 disconnects the memory power bus from the rest of the system during power-down, assuring minimal current drain from the battery. When the P-box is powered up, D3 and R4 provide a trickle charging network for the battery. The three regulator shunt resistors, R5-R7, supply some of the regulated 5 volt logic current, thereby reducing the power (heat) dissipated in the regulator. A voltage divider, composed of R2, R3, and C2, supplies the appropriate backup voltage to the clock chip. 8. Cartridge Emulator Port The design goal for the Cartridge Emulator Port (CEP) is to provide all the signals required to operate a cartridge. The Cartridge Emulator, an optional daughterboard which plugs into the CEP, will function as a loadable cartridge port. With the proper software installed in GRAND RAM, cartridges could be loaded from RAMdisk or floppy disk into the Cartridge Emulator and executed, without ever having a cartridge plugged into the console! A menu of the user's favorite cartridges could be displayed automatically after the TI99/4A is turned on. This would allow the user to select a particular cartridge with a single keypress. The Cartridge Emulator Port provides the following support: a. Four 8K-blocks of memory, which are banked into the cartridge CPU address space from >6000->7fff. Some of the TMS9901 I/O lines are used for controlling the which 8K block is selected. The banking architecture supports ame 99% of the existing cartridges. b. 64K of GRAM, partitioned at the console/cartridge address boundary. This allows for independent control of both console and cartridge grom emulation. Designed by Sofmachine Inc. 3-2 Copyright 1987 DataBioTics GRAND RAM TECHNICAL DATA Hardware Design Cartridge Emulator Port (CEP ) Connector Definition Pin # Name Type Function/Definition --------------------------------------------------------------- 1,2 +U8V PWR Unregulated 8 volt power input 3-10 BD7-BD0 I/O Buffered Data bus. DB7 is Least sig bit 11-26 BA15-BA0 Out Buffered Address Bus. BA15 is least sig bit 27 -BMEMEN Out Buffered and reclocked P-box -MEMEN (active low) 28 -BWE Out Buffered P-box -WE (active low write enable) 29 -LCLDBEN In LoCaL Data Bus ENable (active low). When active, this causes the data bus drivers to be turned on. Drive this line with an open-collecter source. 30 -BDBIN Out Buffered, active low, version of P-box DBIN 31 -ABC Out Active (low) when P-box extended memory bits A, B, and C are all equal to 1. 32 -GRAMSEL Out Active (low) whenever an access occurs in the grom space (>9800->9FFF). 34 CRUBIT4 Out =0 enable gram emulation for console groms (>0000->5FFF) =1 disable emulation for console groms 33 CRUBIT5 Out =0 enable gram emulation for cartridge groms (>6000->FFFF) =1 disable emulation for cartridge groms 36 CRUBIT6 Out =0 enable writes to emulation gram =1 disable writes to emulation gram 35 CRUBIT7 Out =0 enable emulation of cartidge rom/ram memory from >6000->7FFF. =1 disable emulation of cartridge rom/ram memory 38 CRUBIT8 Out =0 CRUBIT9 pages in the upper or lower 8K block for emulation of cartridge rom/ram. Used when loading up a cartridge, or developing new applications. =1 the value of Address bit 14 during the last write to cartridge ram/rom selects the upper or lower 8K block of emulation rom/ram. This maintains compatibility with existing cartridges. 37 CRUBIT9 Out =0 selects the lower 8K block (out of 16K) =1 selects the upper 8K block (out of 16K) 40 CRUBIT10 Out =0 selects the lower 16K block (out of 32K) =1 selects the upper 16K block (out of 32K) This bit, along with either CRUBIT9 or the latched value of BA14, form a page address, which selects of the four 8K blocks from the available 32K of emulation ram. 39 CRUBIT11 Out =0 enable writes to cartridge emulation ram/rom at addresses >6000 - >6FFF. (for ram emulation) =1 disable writes to cartridge emulation ram/rom at addresses >6000 - >6FFF. (for rom emulation) 42 CRUBIT12 Out =0 enable writes to cartridge emulation ram/rom Sofmachine, Inc. 3-4 GRAND RAM TECHNICAL DATA Hardware Design at addresses >7000 - >7FFF. (for ram emulation) =1 disable writes to cartridge emulation ram/rom at addresses >7000 - >7FFF. (for rom emulation) 41 N/C No connection 43,44 GROUND PWR Ground for power and signals 45,45 N/C No connection 9. Device Expansion Port The design goal for the Device Expansion Port (DEP) is to provide all the signals required for a general purpose I/O expansion capability. The DEP provides the following features: a. 224 bytes of predecoded memory-mapped I/O space with an active low polarity. b. Three CRU single bit I/O ports. c. Five interrupt inputs, which are also usable as single CRU inputs bits/ d. Access to the audio input of the 99/4A sound chip. This allows add-on boards to output their sound through the normal 99/4A audio channel, in the same fashion as the speech peripheral. Sofmachine, Inc. 3-5 GRAND RAM TECHNICAL DATA Hardware Design Device Expansion Port (DEP ) Connector Definition Pin # Name Type Function/Definition --------------------------------------------------------------- 1,2 +U8V PWR Unregulated 8 volt power input 3-10 BD7-BD0 I/O Buffered Data bus. DB7 is Least sig bit 11-18 BA15-BA8 Out Partial Buffered Address Bus. BA15 is least sig bit 19 -EXPIO Out Active (low) when an address access in the range of >4F00 - >4FDF, and the proper CRU bits are set up. See the memory map for required CRU values to activate this signal. 20 -BWE Out Buffered P-box -WE (active low write enable) 21 -PH3 Out Buffered 3 MHz negaged phase 3 P-box signal 22 -BDBIN Out Buffered, active low, version of P-box DBIN 23 READY In Ready to the 99/4A processor. To extend a memory cycle, drive this line low with an open-collector output. 24 -INT1 In Active low interrupt input to the TMS9901 INT1 input. This line is pulled up to +5V with a resistor on the GRAND RAM board. 26 -INT9901 Out Active low interrupt output from the TMS9901 With proper software, this output can be programmed to supply a pulse at a rate determined by the 9901 interval timer. This would be useful as a very stable and controllable sample pulse for A/D and D/A converters, etc. 25 CRUBIT13 I/O General-purpose CRU I/O bit 28 CRUBIT14 I/O General-purpose CRU I/O bit 27 CRUBIT15 I/O General-purpose CRU I/O bit 29 AUDIO In External audio input to console sound chip 30 -INT2 In Interrupt or general purpose input 32 -INT4 In Interrupt or general purpose input 31 -INT5 In Interrupt or general purpose input 34 -INT6 In Interrupt or general purpose input 33 N/C No Connection 35,36 GND PWR Ground for power and signals 37,38 N/C No connection Sofmachine, Inc. 3-6 GRAND RAM TECHNICAL DATA Hardware Design MEMORY MAP +--------------------+--------------------+ | CRUBIT0 = 1 | CRUBIT0 = 1 | | CRUBIT2 = 0 | CRUBIT2 = 1 | |--------------------+--------------------| >4000| | | RAM PAGE 0 | >47FF| | |--------------------|--------------------| >4800| | | RAM PAGE 1 | >4EFF| | |--------------------|--------------------| >4F00| | | | EXPANSION | | | PORT I/O | | >4FDF| | | |--------------------| | >4FEO| PAGE REGISTER #0 | | |--------------------| | >4FE1| UNUSED | | |--------------------| | >4FE2| PAGE REGISTER #1 | | |--------------------| | >4FE3| UNUSED | | |--------------------| | >4FE4| CLOCK WRITE | RAM PAGE 1 | |--------------------| | >4FE5| UNUSED | | |--------------------| | >4FE6| CLOCK READ | | |--------------------| | >4FE7| UNUSED | | |--------------------| | >4FE8| >4FE0 - >4FE7 | | | is mirrored in | | | in this space | | >4FFF| | | |--------------------|--------------------| >5000| | | RAM PAGE SELECTED BY | | PAGE REGISTER #0 | >57FF| | |-----------------------------------------| >5800| | | RAM PAGE SELECTED BY | | PAGE REGISTER #1 | >5FFF| | |-----------------------------------------| Sofmachine, Inc. 3-7 ============================================================================ DTIHM038 THE PAL12L6 OF THE MYARC FLOPPY DISK CONTROLLER @Paolo Bagnaresi, February 1990 - % - THE PAL12L6 OF THE MYARC FLOPPY DISK CONTROLLER =============================================== Author: Paolo Bagnaresi Via J.F. Kennedy 17 20097 San Donato Milanese Italy Date: February 10, 1990 Disclaimer: although this document has been written to the best of my knowledge, it may be unaccurate or misleading. It is also unknown to me if the Myarc program burned inside the PAL has been copyrighted. If it has, you may not be allowed to use this document to duplicate the Myarc FDC PAL and usage or distributing of this document may be prohibited by the law. In any case, the informations provided by this document have been entirely worked out without assistance or help from Myarc. Purpose of this document ------------------------ This document will explain the usage of the PAL12L6 chip (National Semiconductor, Monolithic Memories, etc.) located inside the Myarc FDC. The PAL12L6 is a 20 pin, 12 dedicated inputs, 6 combinatorial outputs, Programmable Array Logic. Input pins are pins # 1,2,3,4,5,6,7,8,9,11,12,19. Output pins are pins # 13,14,15,16,17,18. This PAL acts as a "glue logic" inside the Myarc FDC. It has been used by Myarc to enable the following devices inside the FDC: 1) 74LS259 when a CRU OUT cycle the CRU address range >1100 - >11FF was executed 2) 74LS251 when a CRU IN cycle the CRU address range >1100 - >11FF was executed 3) 2764 Eprom when a Memory cycle in the address range >4000 - >4FFF was executed 4) 2024 Static Ram when a Memory cycle in the address range >5000 - >57FF was executed 5) WD1770 Read/Write Registers when a Memory cycle in the address range >5F00 - >5FFF was executed First off, I will describe how the PAL has been programmed. Then, the fuse blowing layout will be translated into a more understandable circuit layout and the suitable explanations will be given. The following SPRINT XPLOT listing has been obtained by analysing the PAL12L6 of Myarc Floppy Disk Controller by the "SPRINT PAL Programmer". Inspection was possible since Myarc did not blow the Security Fuse on the PAL after programming. The SPRINT XPLOT listing has been provided by Roberto Maffioletti, Via Magellano 8, 24040 Stezzano, Bergamo, Italy. I would like to thank Roberto for his invaluable help. *------------------------------------------------------------ SPRINT XPLOT listing of device N.S. DMPAL12L6 file 0000 0000 0011 1111 1111 2222 2222 2233 term pin 0123 4567 8901 2345 6789 0123 4567 8901 8 18 -XX- X--X -X -X -X -X ---X --X- 9 XXXX XXXX XX XX XX XX XXXX XXXX 10 XXXX XXXX XX XX XX XX XXXX XXXX 11 XXXX XXXX XX XX XX XX XXXX XXXX 16 17 X-X- X--X X- X- X- -X X--- X--X 17 XXXX XXXX XX XX XX XX XXXX XXXX 24 16 -XX- X--X -X -X -X -X ---- --X- 25 XXXX XXXX XX XX XX XX XXXX XXXX 32 15 ---- ---X X- -- -- -X ---- X--X 33 XXXX XXXX XX XX XX XX XXXX XXXX 40 14 ---- X--X X- -X -- -X ---- X--X 41 XXXX XXXX XX XX XX XX XXXX XXXX 48 13 ---- -X-X X- -- -- -X ---- X--X 49 XXXX XXXX XX XX XX XX XXXX XXXX 50 XXXX XXXX XX XX XX XX XXXX XXXX 51 XXXX XXXX XX XX XX XX XXXX XXXX Note: X = Fuse not blown - = Fuse blown *------------------------------------------------------------ Now, from the above SPRINT XPLOT listing you can easily build back the Fuse Link Map by marking an "X" on the logic diagram of the PAL12L6 (the diagram has not provided with this document, since its complexity far exceeds the drawing capabilities of TI-Writer). Please refer to the National Semiconductor "PROGRAMMABLE LOGIC DEVICES, Databook and Design Guide", for the PAL12L6 Fuse Link Map Diagram. From the so otained diagram, we will try to describe to what input pin each output pin in the PAL is connected. In the following drawing, the AND gate is represented as such I ---------|\ Note: the "-----0|" means n --------0| \ that the input p ---------| )-- Output signal is negated u ---------| / before being used t ---------|/ by the PAL array. Also, the OR gate is represented as such: \ \ Input --)>---- Output Input --)>0---- Negated Output / / ============================================================= PAL PIN 18 ---------- Line Input AND OR Output Output Name Pin Pin Description A07_B--------------1---|\ To G* (pin 14 A06_B--------------2--0| \ Chip Enable) A03----------------3---| \ of U10 A01----------------4---| \ 74LS259. A04_B--------------5--0| \ \ A05_B--------------6--0| )--)>0---Pin # 18 A00----------------7--0| / / MEMEN*------------11---| / CRUCLK------------12---| / A02---------------19---| / Address Lines decode -------------------- Address Line # 0123 4567 Weight 8421 8421 Address value 0001 0001 Hex Addr. value >11xx Output pin purpose ------------------ Sees if a CRU OUT data bit is aimed to the FDC card. CRU OUT data bit coming from 9900 are accepted by the card if : a) Address is >11xx in the Address Lines b) MEMEN* is HIGH (inactive) c) CRUCLK* is LOW (active) ============================================================= PAL PIN 17 ---------- Line Input AND OR Output Output Name Pin Pin Description A07_B--------------1---|\ To CS* (pin 1 A06_B--------------2---| \ Chip Enable) A03----------------3---| \ of U6 WD1770 A01----------------4---| \ Floppy Disk A04_B--------------5---| \ \ Controller. A05_B--------------6---| )--)>0---Pin # 17 A00----------------7--0| / / A15_B_CRU_OUT------8---| / CRU_BIT_ZERO_ON----9---| / MEMEN*------------11--0| / A02---------------19--0|/ Address Lines decode -------------------- Address Line # 0123 4567 Weight 8421 8421 Address value 0101 1111 Hex Addr. value >5Fxx Output pin purpose ------------------ Sees if a memory cycle (Memory Read/Write) is aimed to the Read/Write Registers of WD1770 chip (Floppy Disk controller) in the FDC card. Condition is true if: a) Address is >5Fxx in the Address Lines b) Address is also ODD (not EVEN) c) MEMEN* is LOW (active) d) The card has been already opened. That is, if the CRU BIT ZERO at Base >1100 has been already turned to ON state. ============================================================= PAL PIN 16 ---------- Line Input AND OR Output Output Name Pin Pin Description A07_B--------------1---|\ To STROBE A06_B--------------2--0| \ (Pin 7) of A03----------------3---| \ U5 74LS251 A01----------------4--0| \ Data Selector A04_B--------------5--0| \ \ A05_B--------------6--0| )--)>0---Pin # 16 A00----------------7--0| / / MEMEN*------------11---| / A02---------------19--0| / | / |/ Address Lines decode -------------------- Address Line # 0123 4567 Weight 8421 8421 Address value 0001 0001 Hex Addr. value >11xx Output pin purpose ------------------ Sees if a CRU IN cycle is aimed to the FDC card. Enables sending CRU data bit from the Myarc FDC card to the 9900, through the CRUIN data line, if: a) Address is >11xx in the Address Lines b) MEMEN* is HIGH (inactive) Note: in the Myarc FDC card, the CRUIN cycle decoding is equal to the CRUOUT cycle decoding. This means that during a CRUOUT cycle in the >11xx CRU address range the U5 74LS251 is selected anyway and a DATA BIT is sent to the 9900 as if CRUIN cycle had been executed. However, this approach does no harm since the the CRUIN line is a dedicated line and the 9900 simply ignores the bit value being presented on the CRUIN line during a CRUOUT cycle. ============================================================= PAL PIN 15 ---------- Line Input AND OR Output Output Name Pin Pin Description A01----------------4---|\ To RDBENA* Bus A00----------------7--0| \ \ Pin in the PEB CRU_BIT_ZERO_ON----9---| )--)>0---Pin # 15 MEMEN*------------11--0| / / A02---------------19--0|/ Address Lines decode -------------------- Address Line # 012 Weight 842 Address value 010 Hex Addr. value >4xxx - >5xxx Output pin purpose ------------------ Sees if a memory cycle is aimed to the FDC card. Asserts REMOTE DATA BUS ENABLE (RDBENA*) to its active state (LOW) if: a) Address is in the range >4xxx - >5xxx b) MEMEN* is LOW (active) c) The card has been already opened. That is, if the CRU BIT ZERO at Base >1100 has been already turned to ON state. ============================================================= PAL PIN 14 ---------- Line Input AND OR Output Output Name Pin Pin Description A03----------------3---|\ To CE* (pin A01----------------4---| \ 18, Chip A04_B--------------5--0| \ \ Enable) of A00----------------7--0| )--)>0---Pin # 14 U2 2016 CRU_BIT_ZERO_ON----9---| / / Static Ram MEMEN*------------11--0| / (2 Kbytes) A02---------------19--0|/ Address Lines decode -------------------- Address Line # 0123 4 Weight 8421 8 Address value 0101 0 Hex Addr. value >50xx - >57xx Output pin purpose ------------------ Sees if a memory cycle is aimed to the 2 K Static Ram in FDC card. Enables the 2 K Static Ram in the address range >50xx - >57xx if: a) Address is in the range >50xx - >57xx b) MEMEN* is LOW (active) c) The card has been already opened. That is, if the CRU BIT ZERO at Base >1100 has been already turned to ON state. ============================================================= PAL PIN 13 ---------- Line Input AND OR Output Output Name Pin Pin Description |\ A03----------------3--0| \ To CE* (pin A01----------------4---| \ \ 20, Chip A00----------------7--0| )--)>0---Pin # 13 U3 2764 CRU_BIT_ZERO_ON----9---| / / Eprom MEMEN*------------11--0| / (8 Kbytes) A02---------------19--0|/ Address Lines decode -------------------- Address Line # 0123 Weight 8421 Address value 0100 Hex Addr. value >4xxx Output pin purpose ------------------ Sees if a memory cycle is aimed to the 8 K Eprom in FDC card. Enables the 8 K Eprom in the address range >4xxx if: a) Address is in the range >4000 - >4FFF b) MEMEN* is LOW (active) c) The card has been already opened. That is, if the CRU BIT ZERO at Base >1100 has been already turned to ON state. Note: The Eprom is logically divided into two banks, each being 4 KBytes long and each residing in the address range >4000 - >4FFF. When the Eprom is accessed, which Eprom bank will be paged-in depends on the state of CRU OUT Bit # 3, which has also another function: it enables the Double Density when reading/writing from/to Floppy Disk. This particular hardware arrangements creates a problem: the software residing in the Eprom cannot directly turn on/off the Single/Double Density. If it does, the other Eprom bank may get turned on and the microprocessor would start executing the code residing in the other side of the Eprom. The problem is software solved by relocating a short portion of code in the Scratch Pad area (>8300 - >83FF) just prior to accessing the Floppy Disk Drive. Then, execution will be transfered to this code relocated in the Scratch Pad area. The selected density can be safely enabled and, after the transfer from/to the Floppy Disk has been carried out, the density pertaining to the Eprom bank being used will be restored to its previous state. Eventually, a return to the original Eprom bank will be performed. Also, it's worth noting that the code relocation to the Scratch Pad area ensures a 16 bit fast execution, as opposed to the 8 bit/wait state/8 bit slow execution that would take place for code executing from inside the Eprom. * Filename : MYARC-FDC1 - Actual code example is on files 80T-INIT-A thru D **************************************************************************** * MYARC DISK CONTROLLER CRU INFORMATIONS ******************************************************************************** Paolo Bagnaresi Via Kennedy 17 20097 San donato Milanese ITALY - Phone (02)-514.202 ******************************************************************************** The following informations are accurate and to the best of my knowledge. However, you should not assume they are free from errors. I will gladly accept any correction that you will send to my address. Please feel free to contact me on this matter. I am trying to share informations on this subject in the hope of receiving some feed back from other users: I would like to know YOUR PERSONAL EXPERIENCES. PLEASE WRITE ME BACK. ******************************************************************************** The MYARC Disk Controller (from now on MDC) is a card to be fitted in the PEB. It provides DS/DD diskette formatting and some other useful routines. This doc deals primarily with the CRU arrangement onf the MDC, that is somehow different from TI, ATRONIC and CORCOMP disk Controller. The MDC has usually a CRU base address of >1100. Inside, the MDC you can see, among the other chips: - 1 EPROM 4164 (8 Kbytes) - 1 2 Kbyte Ram. - 1 WD 1770 Disk controller The EPROM is banked into two 4 k portions. Each portion is addressed between >4000 and >4FFF. CRU Address >1100 turns on the first bank. Additionally, CRU address >1106 turns on the second bank. The 2 K Ram is addressed from >5000 to >57FF. Addresses between >5800 - >5EFF are unused. Adresses between >5F00 and >5FFF are reserved for I/O mapping (WD 1770 gates, see below). Banking the 4 K Eprom will not affect the Ram. Thus, the Ram can be "seen" from both Eprom banks. This is very convenient. The Ram is used to keep informations relevant to drive usage and to save part of the Scracth pad. Also, the Ram will act as temporary Buffer, for a read from disk. The usage of WD 1770 chip (28 pins) is fully described in the WESTERN DIGITAL "1986 Storage Management Products Handbook". This is the address of Western Digital: WESTERN DIGITAL CORPORATION 2445 McCabe Way Irvine, CA 92714, USA Phone (714)-863.0102. TWX 910-595-1139 GATES (HARDWARE MAPPED GATES TO DISK CONTROLLER) ================================================ These are special CPU RAM addresses that act as a gate to and from the disk controller WD 1770. They are 8 bits gates (a full byte). Please refer to the Western Digital Manual (see above) for a full description on how to use these gates. In the following range of addresses, only odd byte addresses between >5F01 and >5F07 are fully decoded; other odd address are the copy of odd addresses between >5F01 and >5F07: thus, >5F09 should act as >5F01. The even addresses on the same range are without effect. >5F01 = READ : STATUS REGISTER. = WRITE : COMMAND REGISTER. >5F03 = WRITE : CURRENT TRACK ADDRESS. >5F05 = WRITE : NEEDED SECTOR REGISTER. See a note below. >5F07 = READ : READ DATA GATE = WRITE : WRITE DATA GATE In the following descrition the CRU BASE is assumed to be >1100. All SBO, SBZ, TB, LDCR, STCR will have >1100 as a CRU BASE. TB INSTRUCTIONS (Test Bit istructions) ====================================== CRU BASE + 0 = TB 0 : COMMAND COMPLETED TEST. After issuing a Command to >5F01, COMMAND REGISTER GATE, you may want to check if the command has already been performed . This will avoid issuing a new command before completion of the current command. The TB will return 1 if Command has been completed, 0 if not completed. Example: TB 0 JEQ DONE CRU BASE + 2 = TB 1 : DATA REQUEST READY TEST. When reading or writing data to the >5F07 READ/WRITE DATA GATE, some time may elapse before the data is processed by the WD 1770 chip. By checking this CRU BIT you will know when a new data is ready to be processed. If a 1 is returned, then the gate is READY to process a new data. If a 0 is returned, the gate is not ready. Example: TB 1 JEQ READY CRU BASE + 4 = TB 2 : VERIFY HARD DISABLED if set to ZERO. Myarc suggests to run a jumper, inside the Myarc Disk Controller, between pin # 2 of U5 [a 74LS251] and ground to disable VERIFY after a write. The means for the software to detected if this jumper has been run is a TB 2. The only time this bit is tested is after a Write Sector. Example : TB 2 JNE DISABL (Jump if Verify is DISABLed) BASE + 6 = TB 3 : ?? unknown. Apparently is never used. CRU BASE + 8 = TB 4 : DRIVE # 4 80 TRACK DIP-SWITCH SELECTED TEST. This CRU Bit reflects the condition of the internal Dip-Switch # 4, relative to drive # 4 (can be either on ON or on OFF position). It returns 1 if the dip-switch is OFF, 0 if the dip-switch is ON. The dip-switch has to be turned on if the corresponding drive is an 80 track drive (such as TEAC FD 55 F). Please note that this CRU BIT depends only on the position of the corresponding Dip-Switch: it is not capable of really detecting the kind of drive connected. In other words, it is entirely possible that user has a 40 track drive and by mistake turned on the dip-switch: then the softwre will act as if an 80 track is connected .... with all the problem you can easily imagine. Example : TB 4 JNE TRAK80 jump if DIP-SWITCH is OFF. CRU BASE + 10 = TB 5 : DRIVE # 3 80 TRACK DIP-SWITCH SELECTED TEST. This CRU bit reflects the condition of the internal Dip-Switch # 3, relative to drive # 3 (can be either on ON or on OFF position). It returns 1 if the dip-switch is OFF, 0 if the dip-switch is ON. See explanations for TB 4. Example: TB 5 JNE TRAK80 jump if DIP-SWITCH is OFF. CRU BASE + 12 = TB 6 : DRIVE # 2 80 TRACK DIP-SWITCH SELECTED TEST. This CRU bit reflects the condition of the internal Dip-Switch # 2, relative to drive # 2 (can be either on ON or on OFF position). It returns 1 if the dip-switch is OFF, 0 if the dip-switch is ON. See explanations for TB 4. Example: TB 6 JNE TRAK80 jump if DIP-SWITCH is OFF. CRU BASE + 14 = TB 7 : DRIVE # 1 80 TRACK DIP-SWITCH SELECTED TEST. This CRU bit reflects the condition of the internal Dip-Switch # 1, relative to drive # 1 (can be either on ON or on OFF position). It returns 1 if the dip-switch is OFF, 0 if the dip-switch is ON. See explanations for TB 4. Example: TB 7 JNE TRAK80 jump if DIP-SWITCH is OFF. SBO, SBZ INSTRUCTIONS (Set cru Bit to One, Set cru Bit to Zero) =============================================================== CRU BASE + 0 = SBO 0 : ENABLE MYARC DSR CARD SBZ 0 : DISABLE MYARC DSR CARD CRU BASE + 2 = SBO 1 : ?? (may be WD 1770 Chip Enable) SBZ 1 : ?? ( " " " " Chip Disable) CRU BASE + 4 = SBO 2 : ENABLE SECOND SIDE OF MAGNETIC HEAD SBZ 2 : ENABLE FIRST SIDE OF MAGNETIC HEAD CRU BASE + 6 = SBO 3 : ENABLE SINGLE DENSITY AND BANK 2 OF EPROM MEMORY ADDRESSES BETWEEN >4000 AND >4FFF. SBZ 3 : ENABLE DOUBLE DENSITY AND BANK 1 BETWEEN >4000 AND >4FFF. CRU BASE + 8 = SBO 4 : ENABLE DRIVE # 1 SBZ 4 : DISABLE DRIVE # 1 CRU BASE + 10 = SBO 5 : ENABLE DRIVE # 2 SBZ 5 : DISABLE DRIVE # 2 CRU BASE + 12 = SBO 6 : ENABLE DRIVE # 3 SBZ 6 : DISABLE DRIVE # 3 CRU BASE + 14 = SBO 7 : ENABLE DRIVE # 4 SBZ 7 : DISABLE DRIVE # 4 >5F05 GATE (HARDWARE MAPPED SECTOR GATE TO DISK CONTROLLER) =========================================================== The sector # to write to disk Gate is the sector # relative to the track (INTERNAL SECTOR #). When a diskette is initialized, each track contains several sectors (they span from 0 up to either 9 or 18, depending on the density you are using). So, in each track, the sector # is numbered from 0 up to 18. When accessing a LOGICAL sector number, say sector LOGICAL SECTOR # 70, you have to compute the corrisponding TRACK # and INTERNAL SECTOR #. For instance, if the diskette has been initialized to 18 sectors, then LOGICAL SECTOR 70 is = TRACK # 3 (Integer of 70/18) = INTERNAL SECTOR 16 (Remainder of 70/18) Thus, you will write 16 to the >5F05 SECTOR GATE and 3 to the >5F03 TRACK GATE. INTERNAL RAM ORGANIZATION ========================= As said above, the 2 K RAM inside the MDC (>5000 - >57FF) it is used to store information relevant to Disk Management. The following map is a partial description of the use of this RAM. Further infos are needed to complete the map. Please help! >5000 - >501F = Workspace used by Sector READ/WRITE and Disk FORMATTING. >5020 - >508B = Save SCRATCH PAD HIGH AREA (>6C bytes from >8394 through >83FE). >508C - >50AE = Subprogram or Program invoked by the DSRLNK. Here will be stored the Subprogram you call (Ex. >0111 for a Disk Formatting routine), or a full PAB description if you call a Program (>0500,>1000,>0000,>2100,>000A,'DSK1.UTIL1' for a LOAD MEMORY IMAGE PROGRAM of a file 'UTIL1' from Drive 1). >50AF - = Byte: # of maximum RETRY during a READ/WRITE sector. It is initialized to 5 upon entering the READ/WRITE sector routine. The Read/Write Sector software will enable retrying 5 times before issuing error when accessing a sector. A LOST DATA during a read or a write sector will not modify this value (you still have 5 more chances). After a Write Sector error, Sector Zero of the diskette is read. If a new error is issued after reading sector Zero, then DENSITY value is changed and sector Zero is accessed again. This DENSITY swapping and reding Sector ZERO is continued until either sector zero is read succesfully, or RETRY times remains greater than ZERO. After that, a final error is issued to the routine that called the READ/WRITE sector.. On the other hand, if Sector Zero is read succesfully, then the original assigned sector is accessed again. A new error will restart the ZERO READ SECTOR PROCEDURE. >50B0 - >50B1 = Drive # accessed (at >50B1). Usually >50B0 is zero. >50B2 = Byte: if 0 then SECTOR ZERO doesn't need to be updated. If different from zero, then SECTOR ZERO needs updating. >50B3 = Byte: Drive # previously accessed. After computer RESET is always zero. >50B4 - >50B5 = unknown *----- DISKETTE TYPE INFORMATION AREA ---------------------------------------* *----- DRIVE 1 -----* >50B6 - >50B7 = Word: Drive 1 Maximum # of sector/disk. This value is taken from sector ZERO, offset >10, of the diskette you are using. It is always updated whenever you access sector ZERO. It will be: >0168 for 360 sectors >0280 " 640 " >02D0 " 720 " >0500 " 1280 " >05A0 " 1400 " >0A00 " 2560 " >0B40 " 2880 " >50B8 = Byte: Flag for Drive # 1 when an 80 Track Drive is used with a 40 track diskette. If the Most Significant Bit of this byte is set to 1, then the drive is an 80 track drive, but the diskette is a 40 track diskette. In other words, this bit flag enables double step of magnetic head in read a write operations. >50B9 = Byte: Drive 1 SECTOR/TRACK. Usually is either >09 (Single Density, or >10 (Double Density 16 Sector/Track) or >12 (Double Density 18 Sector/Track). *----- DRIVE 2 -----* >50BA - >50BB = Word: Drive 2 Maximum # of sector/disk. This value is taken from sector ZERO, offset >10, of the diskette you are using. It is always updated whenever you access sector ZERO. It will be: >0168 for 360 sectors >0280 " 640 " >02D0 " 720 " >0500 " 1280 " >05A0 " 1400 " >0A00 " 2560 " >0B40 " 2880 " >50BC = Byte: Flag for Drive # 2 when an 80 Track Drive is used with a 40 track diskette. If the Most Significant Bit of this byte is set to 1, then the drive is an 80 track drive, but the diskette is a 40 track diskette. In other words, this bit flag enables double step of magnetic head in read a write operations. >50BD = Byte: Drive 2 SECTOR/TRACK. Usually is either >09 (Single Density, or >10 (Double Density 16 Sector/Track) or >12 (Double Density 18 Sector/Track). *----- DRIVE 3 -----* >50BE - >50BF = Word: Drive 3 Maximum # of sector/disk. This value is taken from sector ZERO, offset >10, of the diskette you are using. It is always updated whenever you access sector ZERO. It will be: >0168 for 360 sectors >0280 " 640 " >02D0 " 720 " >0500 " 1280 " >05A0 " 1400 " >0A00 " 2560 " >0B40 " 2880 " >50C0 = Byte: Flag for Drive # 3 when an 80 Track Drive is used with a 40 track diskette. If the Most Significant Bit of this byte is set to 1, then the drive is an 80 track drive, but the diskette is a 40 track diskette. In other words, this bit flag enables double step of magnetic head in read a write operations. >50C1 = Byte: Drive 3 SECTOR/TRACK. Usually is either >09 (Single Density, or >10 (Double Density 16 Sector/Track) or >12 (Double Density 18 Sector/Track). *----- DRIVE 4 -----* >50C2 - >50C3 = Word: Drive 4 Maximum # of sector/disk. This value is taken from sector ZERO, offset >10, of the diskette you are using. It is always updated whenever you access sector ZERO. It will be: >0168 for 360 sectors >0280 " 640 " >02D0 " 720 " >0500 " 1280 " >05A0 " 1400 " >0A00 " 2560 " >0B40 " 2880 " >50C4 = Byte: Flag for Drive # 4 when an 80 Track Drive is used with a 40 track diskette. If the Most Significant Bit of this byte is set to 1, then the drive is an 80 track drive, but the diskette is a 40 track diskette. In other words, this bit flag enables double step of magnetic head in read a write operations. >50C5 = Byte: Drive 4 SECTOR/TRACK. Usually is either >09 (Single Density, or >10 (Double Density 16 Sector/Track) or >12 (Double Density 18 Sector/Track). *------ LAST TRACK ACCESSED >50C6 = Byte: Last track accessed of Drive # 1 >50C7 = Byte: " " " of Drive # 2 >50C8 = Byte: " " " of Drive # 3 >50C9 = Byte: " " " of Drive # 4 *-----------------------------------------------------------------------------* >50CA = Word: DSRLNK (or EPROM bank 1) RETURN ADDRESS >50CC = Byte: Flag. If ZERO, the the diskette has been previously accessed. If different from ZERO, then the diskette is handled as if it was never been accessed previously: therefore Sector zero is Read and the DISKETTE TYPE INFORMATION AREA is updated. Also, this byte is <>0 after a Read/Write sector error. >50CD = Byte: Flag. HARD VERIFY DISABLED. It reflects the condition of CRU bit 2 after a TB (TB 2). If ZERO, then VERIFY is ENABLED. PLEASE NOTE THAT A VERIFY IN MYARC DC ONLY IMPLIES READING BACK THE GIVEN SECTOR (to >4000 EPROM, a "deaf" area!). No match between the diskette sector content and the BUFFER area is ever performed This, in my opinion, is a strange approach. Myarc approach is entirely different from TI and CORCOMP, that do allow checking of the written sector against the BUFFER content. The Myarc Verify is based only on CRC, LOST DATA, SECTOR NOT FOUND ERRORS. It does not ensure that all the bytes you have passed to the diskette have been really written on the diskette. If, by any means, you bump into an hardware or software failure AND a different sector is accessed, NO ERROR IS EVER REPORTED! If the >50CD byte is different from ZERO, then VERIFY is disabled. >50CE = Byte: Flag. If ZERO, then the Read/Write sector and Initialize routnes will use the VPD RAM BUFFER. If different from ZERO, then the same routines will use a CPU RAM BUFFER (pointed, as usual, by the sane address in the FAC area. This way is faster than having to deal with VPD buffer. >50CF - = Byte: # of maximum files you can open from Basic or Assembler. It is the # of Files you want to allow with a CALL FILES from Basic. Paolo Bagnaresi, Via J.F. Kennedy 17, San Donato Milanese, Italy ~- % ~- File name : MYARC-FDC2 Stored on disk TECH-NOTES * Filename : MYARC-FDC2 - Actual code example is on files 80T-INIT-A thru D **************************************************************************** * MYARC DISK CONTROLLER INFORMATIONS ******************************************************************************** Paolo Bagnaresi Via Kennedy 17 20097 San donato Milanese ITALY - Phone (02)-514.202 ******************************************************************************** INTERNAL RAM ORGANIZATION (follows from previous file) ========================= >50D0 - >51CF = >100 bytes taken from sector ZERO of the diskette last accessed. This is the standard layout of sector ZERO. >50D0 - >50D9 = 10 bytes: DISKNAME, padded to the right with blancks. >50DA - >50DB = Total sector/disk: >0168 for 360 sectors >0280 " 640 " >02D0 " 720 " >0500 " 1280 " >05A0 " 1400 " >0A00 " 2560 " >0B40 " 2880 " >50DC = Byte: Sector/Track. - >09 = 9 (Single Density) - >10 = 16 (Double Density Myarc) - >12 = 18 (Double Density Myarc or CorComp). >50DD - >50DF = 3 Bytes: 'DSK' identifier. >50E0 = Byte: Disk Proprietary Protection >20 -> Not protected, >50 Protected. >50E1 = Byte: Track/Side. Usually either >28 (40 Track) or >50 (80 Track). >50E2 = Byte: Disk Side. >01 Single Side, >02 Double Side. >50E3 = Byte: Disk Density. >01 Single Density, >02 Double Density. >50E4 - >5107 = All >0000. Reserved area. >5018 ..>51CF = Used sector bit map. The actual lenght depends on a side/density factor. There are: >2D (45) bytes for Single Side/Single Dens. ( 9 Sector/Track) >5A (90) " " Double " / " " ( 9 " / " ) >5A (90) " " Single " /Double " (18 " / " ) >A0 (160) " " Double " / " " (16 " / " ) >B4 (180) " " " " / " " (18 " / " ) DISK BUFFERING AREA: The last FILE CONTROL BLOCK # available is always used before the others. ******************* 1st FILE CONTROL BLOCK= >108 bytes: 8 bytes for description, >100 bytes sector ------------------------------------------------------------------------------- >50D0 = Byte: EOF offset for DIS/VAR type file. It will be zeroed when the file is closed. >51D1 = Byte: Drive # used, real number. It will be zeroed when the file is closed. >51D2 - >52D3 = Sector # where the NAME OF THE FILE is kept. >51D4 - >50D5 = Word: The first nibble is the FILE/TYPE. The second nibble, and the second byte, together, point to the last used sector. >51D6 - >51D7 = Word: Total sectors engaged for this file. >51D8 - >52D7 = >100 bytes brought directly from the NAME OF THE FILE sector. OFFSET >51D8 - >51E1 = >00 10 Bytes= FILENAME >51E2 - >51E3 = >0A Word = >0000 = Reserved >51E4 = >0C Byte = File Status Flag (File Type and Write Protection) >51E5 = >0D Byte = Max # of records per Sector = >03 for a 80 DIS/VAR file. >51E6 - >51E7 = >0E Word = Number of sectors currently allocated. >51E8 = >10 Byte = End Of File offset within the last used sector. >51E9 = >11 Byte = Logical Record Length. >50 for a DIS/VAR 80 file. >51EA - >51EB = >12 Word = # of FIXED length records or # of sectors for VARIABLE length (the bytes are reversed, LSB|MSB should be MSB|LSB. >51EC - >51F3 = >14 4 Words = >0000,>0000,>0000,>0000 : Reserved. >51F4 - >51F6 = >1C 3 Bytes = Sector # of first sector and # of following sectors. Nibble are reversed. Also, if next 3 bytes are not zero, fracturing map. 2nd FILE CONTROL BLOCK = >108 bytes: 8 bytes for description, >100 bytes sector ------------------------------------------------------------------------------- >52D8 = Byte: EOF offset for DIS/VAR type file. It will be zeroed when the file is closed. >52D9 = Byte: Drive # used, real number. It will be zeroed when the file is closed. >52DA - >52DB = Sector # where the NAME OF THE FILE is kept. >52DC - >50DD = Word: The first nibble is the FILE/TYPE. The second nibble, and the second byte, together, point to the last used sector. >52DE - >52DF = Word: Total sectors engaged for this file. >52E0 - >53DF = >100 bytes brought directly from the NAME OF THE FILE sector. OFFSET >52E0 - >52E9 = >00 10 Bytes= FILENAME >52EA - >52EB = >0A Word = >0000 = Reserved >52EC >0C Byte = File Status Flag (File Type and Write Protection) >52ED = >0D Byte = Max # of records per Sector = >03 for a 80 DIS/VAR file. >52EE - >52EF = >0E Word = Number of sectors currently allocated. >52F0 = >10 Byte = End Of File offset within the last used sector. >52F1 = >11 Byte = Logical Record Length. >50 for a DIS/VAR 80 file. >52F2 - >52F3 = >12 Word = # of FIXED length records or # of sectors for VARIABLE length (the bytes are reversed, LSB|MSB should be MSB|LSB. >52F4 - >52FB = >14 4 Words = >0000,>0000,>0000,>0000 : Reserved. >52FC - >52FE = >1C 3 Bytes = Sector # of first sector and # of following sectors. Nibble are reversed. Also, if next 3 bytes are not zero, fracturing map. 3rd FILE CONTROL BLOCK = >108 bytes: 8 bytes for description, >100 bytes sector ------------------------------------------------------------------------------- >53E0 = Byte: EOF offset for DIS/VAR type file. It will be zeroed when the file is closed. >53E1 = Byte: Drive # used, real number. It will be zeroed when the file is closed. >53E2 - >53E3 = Sector # where the NAME OF THE FILE is kept. >53E4 - >53E5 = Word: The first nibble is the FILE/TYPE. The second nibble, and the second byte, together, point to the last used sector. >53E6 - >53E7 = Word: Total sectors engaged for this file. >53E8 - >54E7 = >100 bytes brought directly from the NAME OF THE FILE sector. OFFSET >53E8 - >53F1 = >00 10 Bytes= FILENAME >53F2 - >53F3 = >0A Word = >0000 = Reserved >53F4 = >0C Byte = File Status Flag (File Type and Write Protection) >53F5 = >0D Byte = Max # of records per Sector = >03 for a 80 DIS/VAR file. >53F6 - >53F7 = >0E Word = Number of sectors currently allocated. >53F8 = >10 Byte = End Of File offset within the last used sector. >53F9 = >11 Byte = Logical Record Length. >50 for a DIS/VAR 80 file. >53FA - >53FB = >12 Word = # of FIXED length records or # of sectors for VARIABLE length (the bytes are reversed, LSB|MSB should be MSB|LSB. >53FC - >5403 = >14 4 Words = >0000,>0000,>0000,>0000 : Reserved. >5404 - >5406 = >1C 3 Bytes = Sector # of first sector and # of following sectors. Nibble are reversed. Also, if next 3 bytes are not zero, fracturing map. 4th FILE CONTROL BLOCK = >108 bytes: 8 bytes for description, >100 bytes sector ------------------------------------------------------------------------------- >54E8 = Byte: EOF offset for DIS/VAR type file. It will be zeroed when the file is closed. >54E9 = Byte: Drive # used, real number. It will be zeroed when the file is closed. >54EA - >54EB = Sector # where the NAME OF THE FILE is kept. >54EC - >54ED = Word: The first nibble is the FILE/TYPE. The second nibble, and the second byte, together, point to the last used sector. >54EE - >54EF = Word: Total sectors engaged for this file. >54F0 - >55EF = >100 bytes brought directly from the NAME OF THE FILE sector. OFFSET >54F0 - >54F9 = >00 10 Bytes= FILENAME >54FA - >54FB = >0A Word = >0000 = Reserved >54FC >0C Byte = File Status Flag (File Type and Write Protection) >54FD = >0D Byte = Max # of records per Sector = >03 for a 80 DIS/VAR file. >54FE - >54FF = >0E Word = Number of sectors currently allocated. >5500 = >10 Byte = End Of File offset within the last used sector. >5501 = >11 Byte = Logical Record Length. >50 for a DIS/VAR 80 file. >5502 - >5503 = >12 Word = # of FIXED length records or # of sectors for VARIABLE length (the bytes are reversed, LSB|MSB should be MSB|LSB. >5504 - >550B = >14 4 Words = >0000,>0000,>0000,>0000 : Reserved. >550C - >550E = >1C 3 Bytes = Sector # of first sector and # of following sectors. Nibble are reversed. Also, if next 3 bytes are not zero, fracturing map. 5th FILE CONTROL BLOCK = >108 bytes: 8 bytes for description, >100 bytes sector ------------------------------------------------------------------------------- >55F0 = Byte: EOF offset for DIS/VAR type file. It will be zeroed when the file is closed. >55F1 = Byte: Drive # used, real number. It will be zeroed when the file is closed. >55F2 - >55F3 = Sector # where the NAME OF THE FILE is kept. >55F4 - >55F5 = Word: The first nibble is the FILE/TYPE. The second nibble, and the second byte, together, point to the last used sector. >55F6 - >55F7 = Word: Total sectors engaged for this file. >55F8 - >56F7 = >100 bytes brought directly from the NAME OF THE FILE sector. OFFSET >55F8 - >5601 = >00 10 Bytes= FILENAME >5602 - >5603 = >0A Word = >0000 = Reserved >5604 = >0C Byte = File Status Flag (File Type and Write Protection) >5605 = >0D Byte = Max # of records per Sector = >03 for a 80 DIS/VAR file. >5606 - >5607 = >0E Word = Number of sectors currently allocated. >5608 = >10 Byte = End Of File offset within the last used sector. >5609 = >11 Byte = Logical Record Length. >50 for a DIS/VAR 80 file. >560A - >560B = >12 Word = # of FIXED length records or # of sectors for VARIABLE length (the bytes are reversed, LSB|MSB should be MSB|LSB. >560C - >5613 = >14 4 Words = >0000,>0000,>0000,>0000 : Reserved. >5614 - >5616 = >1C 3 Bytes = Sector # of first sector and # of following sectors. Nibble are reversed. Also, if next 3 bytes are not zero, fracturing map. 6th FILE CONTROL BLOCK = >108 bytes: 8 bytes for description, >100 bytes sector ------------------------------------------------------------------------------- >56F8 = Byte: EOF offset for DIS/VAR type file. It will be zeroed when the file is closed. >56F9 = Byte: Drive # used, real number. It will be zeroed when the file is closed. >56FA - >56FB = Sector # where the NAME OF THE FILE is kept. >56FC - >56FD = Word: The first nibble is the FILE/TYPE. The second nibble, and the second byte, together, point to the last used sector. >56FE - >56FF = Word: Total sectors engaged for this file. >5700 - >57FF = >100 bytes brought directly from the NAME OF THE FILE sector. OFFSET >5700 - >5709 = >00 10 Bytes= FILENAME >570A - >570B = >0A Word = >0000 = Reserved >570C >0C Byte = File Status Flag (File Type and Write Protection) >570D = >0D Byte = Max # of records per Sector = >03 for a 80 DIS/VAR file. >570E - >570F = >0E Word = Number of sectors currently allocated. >5710 = >10 Byte = End Of File offset within the last used sector. >5711 = >11 Byte = Logical Record Length. >50 for a DIS/VAR 80 file. >5712 - >5713 = >12 Word = # of FIXED length records or # of sectors for VARIABLE length (the bytes are reversed, LSB|MSB should be MSB|LSB. >5714 - >571B = >14 4 Words = >0000,>0000,>0000,>0000 : Reserved. >571C - >571E = >1C 3 Bytes = Sector # of first sector and # of following sectors. Nibble are reversed. Also, if next 3 bytes are not zero, fracturing map. ******************************************************************************** >577F Note = Last location in Myarc FDC RAM. ------------------------------------------------------------------------------ DTIHM039 DX-10 Opcodes and Mnemonics. [EDITORS NOTE: DX-10 was the operating system used by Texas Instruments 990 series of Minicomputers. Besides being (mostly) compatable with the 99/4a on the assembly level, much software and hardware development for the 99/4a was done on the mini computers. ] THE FOLLOWING TEXT DEFINES ALL THE POSSIBLE TAGS FOUND IN A DX/10 OBJECT FILE: ------------------------------------------------------------------------------- Field 1: Is always 4 bytes long, and contains a Value or Address in ASCII-HEX. But if it is compressed object code, this field is compressed down to 2 bytes and the data is stored in internal BINARY-WORD format. Field 2: Is always 6 bytes long, and contains Symbol characters, except for its use in the first record of the object file and the first TAG of `0'. During this use, this field is expanded by two bytes, to make room for the 8 byte long `PROGRAM ID' text. Field 3: Is always 4 bytes long, and contains a Module No. from >0000 to >0FFF. Start at >0000 for all DATA segments (DSEG) in the source files. The next Module No. >0001 is for all PROGRAM segments (PSEG), but since it is the default mode for all of the OBJECT code,it is never included in any TAG field. The rest of the Module Numbers from>0002 up until >0FFF are for all the different COMMON segments (CSEG). Each COMMON segment with a different Field 2 (Symbol) is assigned a new Module Number. The number of COMMON segments allowed varies depending on the amount of memory available for the Assembler. Linker and Loader programs; but if it is compressed OBJECT code, this field is compressed down to 2 bytes and the Module Number is stored in internal BINARY-WORD format. ------------------------------------------------------------------------------- SPECIAL TAGs: The 7,8,F,: TAGs are designed to control the file format of the OBJECT file, and are used to check for errors in the last record, and to mark the ends of each file,and the end of the OBJECT file. The `U' TAG is generated by the LOAD directive, and allows the source files to force a symbol and address to be loaded into the REF/DEF table for later use. The `D' TAG is generated by the user and allows the user to have a bias or offset added on all TAGs containing a relocatable address. The G,H,I,K,#TAGs are currently not used or no more information is available on them. T SPECIAL CTRL TAG USE: Field 1 Field 2 Field 3 - ---------------------- ---------------------------- ---------- --------- 7 = Checksum Indicator Checksum Value 8 = Checksum Ignore Any Data Value D = Load Bias or Offset Load Bias (user added) U = Force a REF/DEF load Absolute Address Symbol F = End of Record (line #) : = End of File (99/4 AS) - ---------------------- ---------------------------- ---------- --------- G = H = I = Program Identification K = External Macro REF Relocatable Address of Chain Symbol # = Absolute Value >007F???? ------------------------------------------------------------------------------- ALL & AORG: These TAGs are found in code which is AORG or used to mark Absolute Data (B) like OPcodes, etc. in all other kinds of segments. T ALL & AORG TAG USE: Field 1 Field 2 Field 3 - ---------------------- ---------------------------- ---------- --------- 1 = Entry Point Definition Absolute Address 4 = External References Absolute Address 6 = External Definitions Absolute Address 6 = Load Address Absolute Address B = Data Absolute Value ------------------------------------------------------------------------------- PSEG TAG USE: These TAGs are found in code which is inbetween the PSEG and PEND Assembler Directives. This is the default mode of all code which is not marked with one of the XSEG directives. Also, code marked with the RORG directive will end up as PSEG tagged code. These TAGs define all the PROGRAM segments in an assembled program, and also mark the main-relocatable part of the program. Program ID, (Field 2) is 8 bytes long, instead of the normal 6 byte field,and always is the first TAG in any object file,and only appears once. If the IDT directive was not used in the source file, then this field is padded out with 8 space characters. T PSEG TAG USE: Field 1 Field 2 Field 3 - ---------------------- ---------------------------- ---------- --------- 0 = Program Identification Total Length of all PSEG's Program ID 2 = Entry Point Definition Relocatable Address 3 = External References Relocatable Address of Chain Symbol 5 = External Definitions Relocatable Address of Chain Symbol V = External Secondary REF Relocatable Address of Chain Symbol A = Load Address Relocatable Address C = Data Relocatable Address ------------------------------------------------------------------------------- DSEG TAG USE: These TAGs are found in code which is inbetween the DSEG and DEND Assembler Directives. It defines all DATA segments in a assembled program, and also marks the modifiable segments of the program. The second field in the `M'TAG is fixed to the symbol of `$DATA', and only can appear once in any given object file. T DSEG TAG USE: Field 1 Field 2 Field 3 - ---------------------- ---------------------------- ---------- --------- M = Module Identification Total Length of all DSEG's $DATA >0000 X = External References Relocatable Address of Chain Symbol >0000 W = External Definitions Relocatable Address of Chain Symbol >0000 V = External Secondary REF Relocatable Address of Chain Symbol >0000 S = Load Address Relocatable Address T = Data Relocatable Address ------------------------------------------------------------------------------- CSEG TAG USE: These TAGs are found in code which is inbetween the CSEG and CEND Assembler Directives. It defines all the COMMON Module Segments in an assembled program. Since the COMMON segments are defined as separate modules with unique ID's, then these TAGs are useful in marking the page-relocatable parts of the program. The second field in the `M' TAG is defined by each CSEG [`string'], and can be any 6 byte Symbol. All CSEG directives using the same Symbol, are all considered part of the same module, and are all assigned the same Module No. Any CSEG directives without a Symbol, are all assigned the same default Symbol of`$BLANK' for use in the second field of the `M' TAG. T CSEG TAG USE: Field 1 Field 2 Field 3 - ---------------------- ---------------------------- ---------- --------- M = Modules Identification Length of a certain Module # Symbol Module #. X = External References Relocatable Address of Chain Symbol Module #. W = External Definitions Relocatable Address of Chain Symbol Module #. V = External Secondary REF Relocatable Address of Chain Symbol Module #. P = Load Address Relocatable Address Module #. N = Data Relocatable Address Module #. ------------------------------------------------------------------------------ THE FOLLOWING TEXT DEFINES ALL THE SPECIAL MNEMONICS IN A DX/10 SOURCE FILE: ------------------------------------------------------------------------------- These OPcodes are found in all 9900 based systems starting at the 9900CPU chip, all the way up to the latest 99000 CPU. But due to the fact that these OPcodes output a special CRU address on the system bus, they can't be used correctly in 99/4a type systems. Only the RSET and IDLE should ever be attempted in a 99/4a system, but we don't recommend it. These OPcodes are designed to interface with special CRU hardware to control various user-defined functions. OPCODE Meanings of Mnemonics and Opcodes 0 1 2 3 4 5 6 7 8 9 A B C D E F ---- ----- ---------------------------------- --------------------------------- IDLE >0340 IDLE until a reset, interrupt,load |0 0 0 0 0 0 1 1 0 1 0 0 0 0 0 0| RSET >0360 ReSET status bits 12-15 to zero |0 0 0 0 0 0 1 1 0 1 1 0 0 0 0 0| CKON >03A0 ClocK ON (user) |0 0 0 0 0 0 1 1 1 0 1 0 0 0 0 0| CKOF >03C0 ClocK OFF (user) |0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0| LREX >03E0 Load or REstart eXecution (user) |0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0| ------------------------------------------------------------------------------- These OPcodes are only found in 9940 based systems using the 9940 CPU chip. But since they assemble using the XOP OPcode, it is possible to make them available on other 9900 based systems. On the 99/4a the DCA (XOP 0)vectors are: CRU >1B00 WS >2800, PC >4028 (Extended GPL mode),and for the DCS (XOP 2) the vectors are: WS >FFD8, PC >FFF8. The LIIM opcode is a special verion of the normal LIMI for the 9940, as the 9940 only has max. 4 levels of interrupts and the mormal LIMI allows up to 16 levels of interrupts. The LIIM is not needed on the 99/4a as this system only has one fixed level of interrupts; but if you need to emulate this OPcode for any reason, the vectors on the 99/4a for LIIM (XOP 0) are: WS >83A0, PC >8300. OPCODE Meanings of Mnemonics and Opcodes 0 1 2 3 4 5 6 7 8 9 A B C D E F ---- ----- ---------------------------------- --------------------------------- DCA >2C00 Decimal Correct Addition XOP0 |0 0 1 0 1 1|0 0 0 0| Ts| S | DCS >2C40 Decimal Correct Subtraction XOP1 |0 0 1 0 1 1|0 0 0 1| Ts| S | LIIM >2C80 Load Immediate Interrupt Mask XOP2 |0 0 1 0 1 1|0 0 1 0| x | n | ------------------------------------------------------------------------------- These OPcodes are found in the 990/10 mainframe system, and also in any 99000 based system. They are designed to support the 99610 memory mapper, to allow easy access to another page without the need of switching a page someplace. They can also be emulated in a 9995 based system thru the MID interrupt. OPCODE Meanings of Mnemonics and Opcodes 0 1 2 3 4 5 6 7 8 9 A B C D E F ---- ----- ---------------------------------- --------------------------------- LDS >0780 Long Distance Source |0 0 0 0 0 1 1 1 1 0| Ts| S | LDD >07C0 Long Distance Destination |0 0 0 0 0 1 1 1 1 1| Ts| S | ------------------------------------------------------------------------------- These OPcodes currently are not known about in any 9900 or possible 9900 based system,only the LMF has one small line about it in the 99000 manual. Its format is LMF Rx,x; where the Rx can be any workspace register from 0 thru 15, and the immediate can be a `0' or a `1'. The XIT opcode does not have any operands, and is just used by itself. It is not mentioned in any 9900 or 99000 reference manual, and lloks to me like a special opcode to return or eXIT from something. OPCODE Meanings of Mnemonics and Opcodes 0 1 2 3 4 5 6 7 8 9 A B C D E F ---- ----- ---------------------------------- --------------------------------- LMF >0320 ????(not in any known 9900 system) |0 0 0 0 0 0 1 1 0 0 1|n| W | ---- ----- ---------------------------------- --------------------------------- XIT >0C0E ????(not in any known 9900 system) |0 0 0 0 1 1 0 0 0 0 0 0 1 1 1 0| ------------------------------------------------------------------------------- These OPcodes are only found in 99000 based systems using the 99110A CPU chip. They are designed to provide a floating point package for 9900 based systems; but they can also be emulated in a 9995 based system thru the MID interrupt. OPCODE Meanings of Mnemonics and Opcodes 0 1 2 3 4 5 6 7 8 9 A B C D E F ---- ----- ---------------------------------- --------------------------------- AR >0C40 Add Real |0 0 0 0 1 1 0 0 0 1| Ts| S | CIR >0C80 Convert Integer to Real |0 0 0 0 1 1 0 0 1 0| Ts| S | SR >0CC0 Subtract Real |0 0 0 0 1 1 0 0 1 1| Ts| S | MR >0D00 Multiply Real |0 0 0 0 1 1 0 1 0 0| Ts| S | DR >0D40 Divide Real |0 0 0 0 1 1 0 1 0 1| Ts| S | LR >0D80 Load Real |0 0 0 0 1 1 0 1 1 0| Ts| S | STR >0DC0 Store Real |0 0 0 0 1 1 0 1 1 1| Ts| S | ---- ----- ---------------------------------- --------------------------------- CRI >0C00 Convert Real to Integer |0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0| NEGR >0C02 Negate Real |0 0 0 0 1 1 0 0 0 0 0 0 0 0 1 0| CRE >0C04 Convert Real to Extended integer |0 0 0 0 1 1 0 0 0 0 0 0 0 1 0 0| CRE >0C06 Convert Extended integer to Real |0 0 0 0 1 1 0 0 0 0 0 0 0 1 1 0| ------------------------------------------------------------------------------- These OPcodes are currently not found in any 9900 based system;but if emulated, they are designed to provide an easy-to-use BCDecimal package for 9900 based systems. They can be emulated in a 9995 based system thru the MID interrupt. OPCODE Meanings of Mnemonics and Opcodes 0 1 2 3 4 5 6 7 8 9 A B C D E F ---- ----- ---------------------------------- --------------------------------- AD >0E40 Add Decimal |0 0 0 0 1 1 1 0 0 1| Ts| S | CID >0E80 Convert Integer to Decimal |0 0 0 0 1 1 1 0 1 0| Ts| S | SD >0EC0 Subtract Decimal |0 0 0 0 1 1 1 0 1 1| Ts| S | MD >0F00 Multiply Decimal |0 0 0 0 1 1 1 1 0 0| Ts| S | DD >0F40 Divide Decimal |0 0 0 0 1 1 1 1 0 1| Ts| S | LD >0F80 Load Decimal |0 0 0 0 1 1 1 1 1 0| Ts| S | STD >0FC0 Store Decimal |0 0 0 0 1 1 1 1 1 1| Ts| S | ---- ----- ---------------------------------- --------------------------------- CDI >0C01 Convert Decimal to Integer |0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 1| CDE >0C05 Convert Decimal to Extended integer|0 0 0 0 1 1 0 0 0 0 0 0 0 1 0 1| CED >0C07 Convert Extended integer to Decimal|0 0 0 0 1 1 0 0 0 0 0 0 0 1 1 1| ------------------------------------------------------------------------------ THE FOLLOWING TEXT DEFINES ALL THE OPCODES AND MNEMONICS IN A 9900/99000 SYSTEM OPCODE Meanings of Mnemonics and Opcodes 0 1 2 3 4 5 6 7 8 9 A B C D E F ----- ---- ---------------------------------- --------------------------------- >0000 (16 opcodes available) |0 0 0 0 0 0 0 0 0 0 0 0|- - - -| >0010 ( 8 opcodes available) |0 0 0 0 0 0 0 0 0 0 0 1 0|- - -| >0018 ( 4 opcodes available) |0 0 0 0 0 0 0 0 0 0 0 1 1 0|- -| >001C SRAM Shift Right Arithmetic Multiple 32|0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 0| >001D SLAM Shift Left Arithmetic Multiple 32|0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1| >001E ( 2 opcodes available) |0 0 0 0 0 0 0 0 0 0 0 1 1 1 1|-| >0020 ( 8 opcodes available) |0 0 0 0 0 0 0 0 0 0 1 0 0|- - -| >0028 ( 1 opcode available) |0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0| >0029 AM Add Multiple 32|0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1| >002A SM Subtract Multiple 32|0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0| >002B ( 1 opcode available) |0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 1| >002C ( 4 opcodes available) |0 0 0 0 0 0 0 0 0 0 1 0 1 1|- -| >0030 (16 opcodes available) |0 0 0 0 0 0 0 0 0 0 1 1|- - - -| >0040 (64 opcodes available) |0 0 0 0 0 0 0 0 0 1|- - - - - -| >0080 LST Load STatus register |0 0 0 0 0 0 0 0 1 0 0 0| W | >0090 LWP Load Workspace Pointer |0 0 0 0 0 0 0 0 1 0 0 1| W | >00A0 (16 opcodes available) |0 0 0 0 0 0 0 0 1 0 1 0|- - - -| >00B0 BLSK Branch immediate & Link to StacK |0 0 0 0 0 0 0 0 1 0 1 1| W | >00C0 (64 opcodes available) |0 0 0 0 0 0 0 0 1 1|- - - - - -| >0100 EVAD EValuate ADdress instruction |0 0 0 0 0 0 0 1 0 0| Ts| S | >0140 BIND Branch INDirect |0 0 0 0 0 0 0 1 0 1| Ts| S | >0180 DIVS DIVide-Signed |0 0 0 0 0 0 0 1 1 0| Ts| S | >01C0 MPYS MultiPlY-Signed |0 0 0 0 0 0 0 1 1 1| Ts| S | >0200 LI Load Immediate |0 0 0 0 0 0 1 0 0 0 0 0| W | >0210 (16 opcodes available) |0 0 0 0 0 0 1 0 0 0 0 1|- - - -| >0220 AI Add Immediate |0 0 0 0 0 0 1 0 0 0 1 0| W | >0230 (16 opcodes available) |0 0 0 0 0 0 1 0 0 0 1 1|- - - -| >0240 ANDI AND Immediate |0 0 0 0 0 0 1 0 0 1 0 0| W | >0250 (16 opcodes available) |0 0 0 0 0 0 1 0 0 1 0 1|- - - -| >0260 ORI OR Immediate |0 0 0 0 0 0 1 0 0 1 1 0| W | >0270 (16 opcodes available) |0 0 0 0 0 0 1 0 0 1 1 1|- - - -| >0280 CI Compare Immediate |0 0 0 0 0 0 1 0 1 0 0 0| W | >0290 (16 opcodes available) |0 0 0 0 0 0 1 0 1 0 0 1|- - - -| >02A0 STWP STore Workspace Pointer |0 0 0 0 0 0 1 0 1 0 1 0| W | >02B0 (16 opcodes available) |0 0 0 0 0 0 1 0 1 0 1 1|- - - -| >02C0 STST STore STatus |0 0 0 0 0 0 1 0 1 1 0 0| W | >02D0 (16 opcodes available) |0 0 0 0 0 0 1 0 1 1 0 1|- - - -| >02E0 LWPI Load Workspace Pointer Immediate |0 0 0 0 0 0 1 0 1 1 1 0 0 0 0 0| >02E1 ( 1 opcode available) |0 0 0 0 0 0 1 0 1 1 1 0 0 0 0 1| >02E2 ( 2 opcodes available) |0 0 0 0 0 0 1 0 1 1 1 0 0 0 1|-| >02E4 ( 4 opcodes available) |0 0 0 0 0 0 1 0 1 1 1 0 0 1|- -| >02E8 ( 8 opcodes available) |0 0 0 0 0 0 1 0 1 1 1 0 1|- - -| >02F0 (16 opcodes available) |0 0 0 0 0 0 1 0 1 1 1 1|- - - -| >0300 LIMI Load Interrupt Mask Immediate |0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0| >0301 CR Compare Reals 32|0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 1| >0302 MM Multiply Multiple 32|0 0 0 0 0 0 1 1 0 0 0 0 0 0 1 0| >0303 ( 1 opcode available) |0 0 0 0 0 0 1 1 0 0 0 0 0 0 1 1| >0304 ( 4 opcodes available) |0 0 0 0 0 0 1 1 0 0 0 0 0 1|- -| >0308 ( 8 opcodes available) |0 0 0 0 0 0 1 1 0 0 0 0 1|- - -| >0310 (16 opcodes available) |0 0 0 0 0 0 1 1 0 0 0 1|- - - -| >0320 LMF ????(not in any known 9900 system) |0 0 0 0 0 0 1 1 0 0 1|n| W | >0340 IDLE IDLE until a reset, interrupt,load |0 0 0 0 0 0 1 1 0 1 0 0 0 0 0 0| >0341 ( 1 opcode available) |0 0 0 0 0 0 1 1 0 1 0 0 0 0 0 1| >0342 ( 2 opcodes available) |0 0 0 0 0 0 1 1 0 1 0 0 0 0 1|-| >0344 ( 4 opcodes available) |0 0 0 0 0 0 1 1 0 1 0 0 0 1|- -| >0348 ( 8 opcodes available) |0 0 0 0 0 0 1 1 0 1 0 0 1|- - -| >0350 (16 opcodes available) |0 0 0 0 0 0 1 1 0 1 0 1|- - - -| OPCODE Meanings of Mnemonics and Opcodes 0 1 2 3 4 5 6 7 8 9 A B C D E F ----- ---- ---------------------------------- --------------------------------- >0360 RSET ReSET the status bits 12-15 to zero|0 0 0 0 0 0 1 1 0 1 1 0 0 0 0 0| >0361 ( 1 opcode available) |0 0 0 0 0 0 1 1 0 1 1 0 0 0 0 1| >0362 ( 2 opcodes available) |0 0 0 0 0 0 1 1 0 1 1 0 0 0 1|-| >0364 ( 4 opcodes available) |0 0 0 0 0 0 1 1 0 1 1 0 0 1|- -| >0368 ( 8 opcodes available) |0 0 0 0 0 0 1 1 0 1 1 0 1|- - -| >0370 (16 opcodes available) |0 0 0 0 0 0 1 1 0 1 1 1|- - - -| >0380 RTWP ReTurn with Workspace Pointer |0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 0| >0381 ( 1 opcode available) |0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 1| >0382 ( 2 opcodes available) |0 0 0 0 0 0 1 1 1 0 0 0 0 0 1|-| >0384 ( 4 opcodes available) |0 0 0 0 0 0 1 1 1 0 0 0 0 1|- -| >0388 ( 8 opcodes available) |0 0 0 0 0 0 1 1 1 0 0 0 1|- - -| >0390 (16 opcodes available) |0 0 0 0 0 0 1 1 1 0 0 1|- - - -| >03A0 CKON ClocK ON (user) |0 0 0 0 0 0 1 1 1 0 1 0 0 0 0 0| >03A1 ( 1 opcode available) |0 0 0 0 0 0 1 1 1 0 1 0 0 0 0 1| >03A2 ( 2 opcodes available) |0 0 0 0 0 0 1 1 1 0 1 0 0 0 1|-| >03A4 ( 4 opcodes available) |0 0 0 0 0 0 1 1 1 0 1 0 0 1|- -| >03A8 ( 8 opcodes available) |0 0 0 0 0 0 1 1 1 0 1 0 1|- - -| >03B0 (16 opcodes available) |0 0 0 0 0 0 1 1 1 0 1 1|- - - -| >03C0 CKOF ClocK OFf (user) |0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0| >03C1 ( 1 opcode available) |0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 1| >03C2 ( 2 opcodes available) |0 0 0 0 0 0 1 1 1 1 0 0 0 0 1|-| >03C4 ( 4 opcodes available) |0 0 0 0 0 0 1 1 1 1 0 0 0 1|- -| >03C8 ( 8 opcodes available) |0 0 0 0 0 0 1 1 1 1 0 0 1|- - -| >03D0 (16 opcodes available) |0 0 0 0 0 0 1 1 1 1 0 1|- - - -| >03E0 LREX Load or REstart eXecution (user) |0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 0| >03E1 ( 1 opcode available) |0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 1| >03E2 ( 2 opcodes available) |0 0 0 0 0 0 1 1 1 1 1 0 0 0 1|-| >03E4 ( 4 opcodes available) |0 0 0 0 0 0 1 1 1 1 1 0 0 1|- -| >03E8 ( 8 opcodes available) |0 0 0 0 0 0 1 1 1 1 1 0 1|- - -| >03F0 (16 opcodes available) |0 0 0 0 0 0 1 1 1 1 1 1|- - - -| >0400 BLWP Branch and Load Workspace Pointer |0 0 0 0 0 1 0 0 0 0| Ts| S | >0440 B Branch |0 0 0 0 0 1 0 0 0 1| Ts| S | >0480 X eXecute |0 0 0 0 0 1 0 0 1 0| Ts| S | >04C0 CLR CLeaR operand to zeros |0 0 0 0 0 1 0 0 1 1| Ts| S | >0500 NEG NEGate operand |0 0 0 0 0 1 0 1 0 0| Ts| S | >0540 INV INVert operand |0 0 0 0 0 1 0 1 0 1| Ts| S | >0580 INC INCrement operand by one |0 0 0 0 0 1 0 1 1 0| Ts| S | >05C0 INCT INCrement operand by Two |0 0 0 0 0 1 0 1 1 1| Ts| S | >0600 DEC DECrement operand by one |0 0 0 0 0 1 1 0 0 0| Ts| S | >0640 DECT DECrement operand by Two |0 0 0 0 0 1 1 0 0 1| Ts| S | >0680 BL Branch and Link |0 0 0 0 0 1 1 0 1 0| Ts| S | >06C0 SWPB SWaP Bytes |0 0 0 0 0 1 1 0 1 1| Ts| S | >0700 SETO SET operand to Ones |0 0 0 0 0 1 1 1 0 0| Ts| S | >0740 ABS ABSolute operand |0 0 0 0 0 1 1 1 0 1| Ts| S | >0780 LDS Long Distance Source |0 0 0 0 0 1 1 1 1 0| Ts| S | >07C0 LDD Long Distance Destination |0 0 0 0 0 1 1 1 1 1| Ts| S | >0800 SRA Shift register Right Arithmetic |0 0 0 0 1 0 0 0| count | W | >0900 SRL Shift register Right Logical |0 0 0 0 1 0 0 1| count | W | >0A00 SLA Shift register Left Arithmetic |0 0 0 0 1 0 1 0| count | W | >0B00 SRC Shift register Right Circular |0 0 0 0 1 0 1 1| count | W | >0C00 CRI Convert Real to Integer |0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0| >0C01 CDI Convert Decimal to Integer |0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 1| >0C02 NEGR NEGate Real |0 0 0 0 1 1 0 0 0 0 0 0 0 0 1 0| >0C03 ( 1 opcode available) |0 0 0 0 1 1 0 0 0 0 0 0 0 0 1 1| >0C04 CRE Convert Real to Extended integer |0 0 0 0 1 1 0 0 0 0 0 0 0 1 0 0| >0C05 CDE Convert Decimal to Extended integer|0 0 0 0 1 1 0 0 0 0 0 0 0 1 0 1| >0C06 CER Convert Extended integer to Real |0 0 0 0 1 1 0 0 0 0 0 0 0 1 1 0| >0C07 CED Convert Extended integer to Decimal|0 0 0 0 1 1 0 0 0 0 0 0 0 1 1 1| >0C08 ( 1 opcode available) |0 0 0 0 1 1 0 0 0 0 0 0 1 0 0 0| OPCODE Meanings of Mnemonics and Opcodes 0 1 2 3 4 5 6 7 8 9 A B C D E F _____ ____ __________________________________ _________________________________ >0C09 TMB Test Memory Bit 32|0 0 0 0 1 1 0 0 0 0 0 0 1 0 0 1| >0C0A TCMB Test and Clear Memory Bit 32|0 0 0 0 1 1 0 0 0 0 0 0 1 0 1 0| >0C0B TSMB Test and Set Memory Bit 32|0 0 0 0 1 1 0 0 0 0 0 0 1 0 1 1| >0C0C ( 2 opcodes available) |0 0 0 0 1 1 0 0 0 0 0 0 1 1 0|-| >0C0E XIT ????(not in any known 9900 system) |0 0 0 0 1 1 0 0 0 0 0 0 1 1 1 0| >0C0F ( 1 opcode available) |0 0 0 0 1 1 0 0 0 0 0 0 1 1 1 1| >0C10 (16 opcodes available) |0 0 0 0 1 1 0 0 0 0 0 1|- - - -| >0C20 (32 opcodes available) |0 0 0 0 1 1 0 0 0 0 1|- - - - -| >0C40 AR Add Real |0 0 0 0 1 1 0 0 0 1| Ts| S | >0C80 CIR Convert Integer to Real |0 0 0 0 1 1 0 0 1 0| Ts| S | >0CC0 SR Subtract Real |0 0 0 0 1 1 0 0 1 1| Ts| S | >0D00 MR Multiply Real |0 0 0 0 1 1 0 1 0 0| Ts| S | >0D40 DR Divide Real |0 0 0 0 1 1 0 1 0 1| Ts| S | >0D80 LR Load Real |0 0 0 0 1 1 0 1 1 0| Ts| S | >0DC0 SR Store Real |0 0 0 0 1 1 0 1 1 1| Ts| S | >0E40 AD Add Decimal |0 0 0 0 1 1 1 0 0 1| Ts| S | >0E80 CID Convert Integer to Decimal |0 0 0 0 1 1 1 0 1 0| Ts| S | >0EC0 SD Subtract Decimal |0 0 0 0 1 1 1 0 1 1| Ts| S | >0F00 MD Multiply Decimal |0 0 0 0 1 1 1 1 0 0| Ts| S | >0F40 DD Divide Decimal |0 0 0 0 1 1 1 1 0 1| Ts| S | >0F80 LD Load Decimal |0 0 0 0 1 1 1 1 1 0| Ts| S | >0FC0 SD Store Decimal |0 0 0 0 1 1 1 1 1 1| Ts| S | >1000 JMP unconditional JuMP |0 0 0 1 0 0 0 0| displacement | >1100 JLT Jump if Less Than |0 0 0 1 0 0 0 1| displacement | >1200 JLE Jump if Low or Equal |0 0 0 1 0 0 1 0| displacement | >1300 JEQ Jump if EQual |0 0 0 1 0 0 1 1| displacement | >1400 JHE Jump if High or Equal |0 0 0 1 0 1 0 0| displacement | >1500 JGT Jump if Greater Than |0 0 0 1 0 1 0 1| displacement | >1600 JNE Jump if Not Equal |0 0 0 1 0 1 1 0| displacement | >1700 JNC Jump if No Carry |0 0 0 1 0 1 1 1| displacement | >1800 JOC Jump if On Carry |0 0 0 1 1 0 0 0| displacement | >1900 JNO Jump if No Overflow |0 0 0 1 1 0 0 1| displacement | >1A00 JL Jump if logical Low |0 0 0 1 1 0 1 0| displacement | >1B00 JH Jump if logical High |0 0 0 1 1 0 1 1| displacement | >1C00 JOP Jump if Odd Parity |0 0 0 1 1 1 0 0| displacement | >1D00 SBO Set CRU Bit to One |0 0 0 1 1 1 0 1| displacement | >1E00 SBZ Set CRU Bit to Zero |0 0 0 1 1 1 1 0| displacement | >1F00 TB Test Bit |0 0 0 1 1 1 1 1| displacement | >2000 COC Compare Ones Corresponding |0 0 1 0 0 0| WsD | Ts| S | >2400 CZC Compare Zeros Corresponding |0 0 1 0 0 1| WsD | Ts| S | >2800 XOR eXclusive OR |0 0 1 0 1 0| WsD | Ts| S | >2C00 XOP eXtended OPeration & (DCA,DCS,LIIM)|0 0 1 0 1 1| n | Ts| S | >3000 LDCR LoaD Communication Register |0 0 1 1 0 0| count | Ts| S | >3400 STCR STore Communication Register |0 0 1 1 0 1| count | Ts| S | >3800 MPY MultiPlY |0 0 1 1 1 0| WsD | Ts| S | >3C00 DIV DIVide |0 0 1 1 1 1| WsD | Ts| S | >4000 SZC Set Zeros Corresponding |0 1 0 0| Td| D | Ts| S | >5000 SZCB Set Zeros Corresponding, Byte |0 1 0 1| Td| D | Ts| S | >6000 S Subtract words |0 1 1 0| Td| D | Ts| S | >7000 SB Subtract Bytes |0 1 1 1| Td| D | Ts| S | >8000 C Compare words |1 0 0 0| Td| D | Ts| S | >9000 CB Compare Bytes |1 0 0 1| Td| D | Ts| S | >A000 A Add words |1 0 1 0| Td| D | Ts| S | >B000 AB Add Bytes |1 0 1 1| Td| D | Ts| S | >C000 MOV MOVe words |1 1 0 0| Td| D | Ts| S | >D000 MOVB MOVe Bytes |1 1 0 1| Td| D | Ts| S | >E000 SOC Set Ones Corresponding |1 1 1 0| Td| D | Ts| S | >F000 SOCB Set Ones Corresponding, Byte |1 1 1 1| Td| D | Ts| S | ------------------------------------------------------------------------------- <eof-12.29.96>